I love this talk about money. I think people are greatly
over-estimating the resources needed to make a good JVM language.
We don't need venture capital.
I do not value 1000s of users or a mainstream language. I value being able to solve problems with capable teams and capable tools.
--
I do not value 1000s of users or a mainstream language. I value being able to solve problems with capable teams and capable tools.
What function on the jvm would not have an exception in the return type?
BR
John
pure native parseInt Integer.parseInt :: String -> Int
main _ = println $ parseInt "23"
native currentTimeMillis java.lang.System.currentTimeMillis :: () -> IO Long
data JMap k v = mutable native java.util.Map where
native get :: JMap k v -> k -> IO (Maybe v)
native put :: JMap k v -> k -> v -> IO ()
data HashMap k v = mutable native java.util.HashMap where
native new :: () -> IO (HashMap k v)
pure native trim :: String -> String
I'm going to argue for d) here.
It's quite plainly obvious that constructing a serious language is a prodigious undertaking. Who would do it? Why? Who would put a roof over their head and food in their babes' mouths for the years it would take? Even if you started now, it would probably be 2016 before you had something stable. No, I think a) is out
b) well, the above argument goes for b) as well. You have to construct a compiler for a notoriously "complex" language and then you have to keep this compliant as scala evolves. I might say that this would presumably take as least as much effort as is being put into scalac, which appears to be a lot, judging from scala-internals
c). Maybe you *are* bound to the JVM. "Boss, can we move off the JVM?" "No".
-- Tony Morris http://tmorris.net/
My background is operations management, and I have only recently joined the Scala community. So far I like what I see, but you raise some interesting questions for me. Please be assured these questions are from a naive starting place of inquiry, and not meant to inflame, so please don't flame me as an idiot (though i would deserve it... :-)
1) How is Scala not a "well-designed" language?
2) What is a "well-designed" language? Haskell? Why don't you just switch to Haskell? I have been told by a Haskell developer that its code is faster and much more elegant looking with fewer parentheses, etc.
3) What's keeping people on the JVM? Libraries and platform interoperability and maybe GC?
4) A little off-topic but I just started learning Ruby for another project, and it seems more "clever" but less elegant than Scala, for example the += operand or using = at the end of class names. By the standards of a "well-designed" language above, is Ruby even below Scala? (Ignore for now Ruby is dynamically typed...)
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
-- Tony Morris http://tmorris.net/
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
-- Tony Morris http://tmorris.net/
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I think that instead of creating a new JVM language, why not contribute to and evolve existing languages like Yeti (impure, strict, functional) or Frege (pure, non-strict, functional, Haskell-like for JVM)? Both the projects are very active but the community is very small. With these languages, being on the JVM, we have a nice option to choose between Scala, Yeti, Frege or Clojure for a particular job.
I am really interested in Frege and have done a few programs. Here are some examples:
Native declaration for java.lang.Integer.parseInt:
pure native parseInt Integer.parseInt :: String -> IntWe can call the function like:
main _ = println $ parseInt "23"
Here is an impure native function declaration:
native currentTimeMillis java.lang.System.currentTimeMillis :: () -> IO Long
I want to do better than this. Just because it is not
referentially-transparent does not mean it goes in IO. The IO type
constructor is "all bets are off." But it's not true here. After
all, we happen to know that currentTimeMillis does not read/write
the file system. Where is the type denoting this?
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
To be clear, I despise popularity contests. Scala is in some trouble because of this degenerate aspiration. SIP-18 is a perfect example of an attempt to further popularity, while providing zero (or less than zero) benefit to users of all persuasions. Just recently[1], having forgot SIP-18 existed myself, I had to explain to a class of ~12 people why they are seeing the implications of it. This digression was costly, especially that we were making such excellent progress otherwise.
The popularity aspiration is for losers in my opinion.
[1] http://www.yowconference.com.au/lambdajam/FPscala.html
I love this talk about money. I think people are greatly
over-estimating the resources needed to make a good JVM language. We
don't need venture capital.
I'll give an estimate for a usable prototype:
* 1 week to make a Hindley-Milner, strict, functional JVM language
* 3 days to add laziness via InvokeDynamic (requires Java 8)
* 2 days to add type-classes
* 2 days to add a sane FFI
Is there something I'm missing? I'd much rather use the prototype than
Scala for a lot of things, almost makes it worth the 2 week
investment.
As I said earlier, it has been argued against me that what is "keeping people on the JVM" is nothing more than an illusion. Those people might claim "libraries" or similar, but I am told this is often hyperbole and/or misdirection. The claimant is under the illusion that the JVM is providing benefit where no such thing exists.
On 14/06/13 09:17, Marimuthu Madasamy wrote:
Here is an impure native function declaration:
native currentTimeMillis java.lang.System.currentTimeMillis :: () -> IO Long
I want to do better than this. Just because it is not referentially-transparent does not mean it goes in IO. The IO type constructor is "all bets are off." But it's not true here. After all, we happen to know that currentTimeMillis does not read/write the file system. Where is the type denoting this?
I'm curious as to how does InvokeDynamic help for laziness? Maybe I'm missing something, but are you seriously thinking of regenerating bytecode for memoization or something like that? Because that would be an awful idea and I hope you're only thinking of the benefits of garbage-collectable method-handles, but that's less of a benefit unless you really need to generate bytecode dynamically or to do custom method dispatching that doesn't conform to the default single-dispatch resolution that the JVM does. I fail to see how laziness is helped by InvokeDynamic here. Also, InvokeDynamic is part of JDK 7, why do you need Java 8 for it?
I think you've forgot higher-rank polymorphism. While not being too difficult to implement, add it to Hindley-Milner takes more than a week IMO.
Just wanted to point out the goal for creating a new language is not
to get thousands of users or make a direct Scala competitor in 2
weeks.
The goal for creating a new language is to get a good foundation.
Scala is not a good foundation: just try to work on the compiler, it's
insanely hard to do anything with it. A smaller language would be a
much better place to work.
I want to be able to say "Scala needs X" or "Scala's Y is awful, let's
remove it" but those are not easy. Macros don't help much.
So advocating Scala because of "incremental improvement" is not very
consistent. The point is that we can't easily improve Scala
(I'd fork it today if I could). We need something else to incrementally improve.
Avian is a Java VM, not a Scala compiler.
I have no idea how Paul Phillips is capable of doing so much with
scalac but I'm sure he'd agree that it's incredibly hard to work with.
Many people write large Java systems, that doesn't mean it's easy.
And it sucks that Scala didn't just incrementally improve Java. That
would have been the secret to success. Typesafe should stop
reinventing wheels. Scala is following the symptom of a failed
software project.
In other words, which response to
the JVM situation would you consider is the best use of effort?
a) Construct a JVM language that is well-designed with good legacy
library interoperability.
d) Concede that you are simply doing the best you can with available
tools. Use Scala -- at least you're doing better than the guy down the
road using Java or "Scala as if it were Java."
And it sucks that Scala didn't just incrementally improve Java. That
would have been the secret to success. Typesafe should stop
reinventing wheels. Scala is following the symptom of a failed
software project.
Wow, that's getting a bit melodramatic, isn't it?
Success has always been a matter of having luck with timing and good marketing, NEVER about language quality. Otherwise, please explain PHP.
The proposition of building a better Java is hopelessly broken, because there's nowhere you can go. A better Java already exists and that language is C#. For many of us C# simply does not exist because it's tied to Windows, but back in early 2000 Microsoft was dominating the desktop, the only smartphones worth considering were running Windows Mobile and Microsoft was increasingly winning the server-side too. Microsoft had all the marketing muscle it needed. C# looked poised to be the next Java. We all know how that turned out.
This is why I believe languages that are only a marginal improvement over Java are poised to fail, because Java is like a freight train that survives and grows on inertia alone and the benefits of picking up a language that's only marginally better is outweighed by the advantages of sticking to a language that's dozens of times more popular. This is also why Scala is less popular than it should, because its biggest problem is one of image - it's pretty hard to show to people why another language is better (the Blub paradox).
Scala also has the disadvantage that it attracted many idealists that criticise the language, but really, it doesn't look good when a language's (vocal) community is not satisfied with it.
When it comes to both Java and PHP, there is one lesson that language designers must learn and not forget - the language is important, but it's less important than everything else combined. And we can all learn to disagree on this point, however those who do not learn from history are doomed to repeat it.
for( w <- choose( u, x ) ){ w match case Left( v ) => P; case Right( y ) => Q }
Not quite as succinct, but certainly still on par and clearly readable.
a) Construct a JVM language that is well-designed with good legacy
library interoperability.
b) Construct a Scala-compliant compiler with extensions to accommodate
language improvements and optimisations. This would also address the
speed issue with scalac as a consequence. It would also offer better
external tool support that integrates into the compiler.
Now we can map over that data, do safe things with it and have better
guarantees that our programs do the right thing, since the types are
no longer lies and errors are explicit.
You'd probably also want a way of saying String#length() is pure.
c) Concede the aforementioned argument. You are not bound to the JVM as
much as you formerly claimed. Use a language like Haskell or O'Caml and
reap the benefits.
d) Concede that you are simply doing the best you can with available
tools. Use Scala -- at least you're doing better than the guy down the
road using Java or "Scala as if it were Java."
There are possibly others options I have not thought of. Each of these
has some amount of required effort ranging from nothing to "lots." This
is important to providing an answer. In other words, which response to
the JVM situation would you consider is the best use of effort?
Thank you for any insights you might have.
--
Tony Morris
http://tmorris.net/
Beyond that, sense is that choosing the computational model on which you base your language design is right on point. What model do you think works best?
Regarding the JVM:
Maybe some people are aware of it, maybe some are not: I have spent the last weeks and months on testing and fixing Scala to run on Avian.
If you want proper tail calls, runtime support for continuations, native compilation and embedding, this is the place where you want to be!
If you want better support for laziness, better performance for functional idioms, runtime support for value types, runtime specialization, this is the place where you want to contribute!
The right to fixing the JVM is not some completely new runtime, but a JVM adapted to our needs. This way, all the existing code keeps working while we can build better abstractions for us.
It's interesting you ask because it seems you've made a distinction between functional and monadic as models for basing a language. I say this only because being very new to functional programming, (scala is the first 'functional' language I've used) they are one and the same in my mind, I can't ever imagine using the former without the latter.
Hi!
Just wanted to point out the goal for creating a new language is not
to get thousands of users or make a direct Scala competitor in 2
weeks.
I don't want to dispute your motivation, maybe I just don't get it.
(My general rule is that I only work on stuff which has a positive impact on a reasonable amount of people.)
I don't get the complaints about Scala's Java interop. On the one side it is argued "interop with Java sucks" and on the other side it is argued "there aren't any useful Java libraries which one might want to use". Then why waste time with it?!
Regarding the complaints about the JVM: If you think scalac is too complicated to change, then Avian is everything scalac is not: The implementation is simple, easy to understand and concise. You can sit down and implement all the stuff you want NOW, without reinventing the wheel. Why aren't you all doing that?
The goal for creating a new language is to get a good foundation.
Scala is not a good foundation: just try to work on the compiler, it's
insanely hard to do anything with it. A smaller language would be a
much better place to work.
Of course Scala is really complicated in that department, but seeing all the great stuff like the effect plugin, continuations, the JavaScript plugin, union types, InSynth, the new pattern matcher, ... it seems like a lot of people are able to deal with it.
I want to be able to say "Scala needs X" or "Scala's Y is awful, let's
remove it" but those are not easy. Macros don't help much.
So advocating Scala because of "incremental improvement" is not very
consistent. The point is that we can't easily improve Scala
I'm certainly not one of those smart geniuses like th rest of this mailing list, but I think I have had reasonable success doing exactly that.
(I'd fork it today if I could). We need something else to incrementally improve.
That seems to have worked out well the last time people tried it ... not.
In fact, "we will do X, but from scratch and better in everything!" seems to be a symptom of failed software projects.
Note: I don't dispute that you could build a prototype which would be better than Kotlin or Ceylon from day one, but I think there are tons of options which would be more productive and beneficial to more people:
If you think you can't work on Scala, improve the runtime instead. If you don't care about the runtime, why not just use/adapt one of the existing languages of the ML family?
Bye,
Simon
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
-- Tony Morris http://tmorris.net/
- a simple, core compositional mathematical presentation enjoying both operational and denotational semantics, as well as a proper Curry-Howard orientation
- fundamentally concurrent
- support for reasoning about time and space complexity within the model
- enjoying rich types that include standard structural considerations (as found in functional settings) as well as behavioral considerations, including but not limited to
- expressing concurrency constraints, such as guaranteeing deadlock freedom
- expressing resource constraints, such restricting
- expressing security and information flow constraints
- fits well with existing language design wisdom -- especially monadic structuring of code
- enjoys a modular account of reflection
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hello,
I have a question. I hope you might be able to help me out. The question
can be broadly phrased, "what can be done about the JVM situation?", but
what do I mean by this?
I have some strong opinions that influence any potential answer I might
have. Maybe you don't quite agree and so it changes the question up a
bit, but here they are anyway:
On Scala:
1) Scala is the best available programming language for the JVM.
2) Scala does not do Java (legacy library) inter-operability very well.
3) Scala is not a well-designed language, but is at least better than
other not-so-well-designed JVM languages.
4) Scala is unlikely to be influenced into adhering to better language
design principles. That is, the poor design is likely to continue into
the future.
5) The Scala compiler cannot be worked on easily. Specifically, if
language improvements were to come into consideration, it would be
difficult to implement them with the current compiler.
On "the JVM situation":
5) The so-called library support offered by the JVM is often over-stated
in its utility.
6) The JVM is a platform that is best avoided if possible e.g. a new
project without any commitment would be best served by avoiding the JVM
due to all of its penalties and almost zero benefits.
There exist projects that cannot avoid using the JVM. This situation is
what I will call the JVM situation.
It has been argued to me that the extent to which the JVM cannot be
avoided is often over-stated. That is to say, a project participant may
claim, "but I cannot avoid the JVM!" to which an appropriate response to
such a hasty remark is, "bullshit, think harder." I do not hold a strong
position on this argument and I would like others' opinions on whether
it has merit.
Supposing that the argument fails, we are left with a not-so-rare
situation of having to use the JVM. However, Scala is not very well
designed. What to do about this? Assuming you had a lot of time to
address this problem, I see a number of possibilities:
a) Construct a JVM language that is well-designed with good legacy
library interoperability.
b) Construct a Scala-compliant compiler with extensions to accommodate
language improvements and optimisations. This would also address the
speed issue with scalac as a consequence. It would also offer better
external tool support that integrates into the compiler.
c) Concede the aforementioned argument. You are not bound to the JVM as
much as you formerly claimed. Use a language like Haskell or O'Caml and
reap the benefits.
d) Concede that you are simply doing the best you can with available
tools. Use Scala -- at least you're doing better than the guy down the
road using Java or "Scala as if it were Java."
There are possibly others options I have not thought of. Each of these
has some amount of required effort ranging from nothing to "lots." This
is important to providing an answer. In other words, which response to
the JVM situation would you consider is the best use of effort?
Thank you for any insights you might have.
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Scala does some awesome stuff, but the existence of subclassing will always hold it back.
b. Fjord - F# on JVM
Why are you even asking these laborious, mechanical questions? How much effort do you spend on answering them? This is not your job -- it is the job of tools and of Java inter-operability. Therefore, Scala does not do this well.
Because I cannot do all the stuff I want. Not even close. Ultimately, it is a false economy, that's why.
I contend that no, a lot of people are not able to deal with it (the consequences of Scala's shortfalls alluded to here-in). Indeed, very few are able to deal with it. I watch this happen before my very eyes with remarkable consistency. It might be my bias, but I see it in person, on mailing lists, on forum posts and I very rarely see any counter-examples. Convince me otherwise.
Scala cannot incrementally improve for a very long list of technical and social reasons. I am not going to waste any more time hoping otherwise. I have already spent a lot of time doing that.
In terms of pure language, Idris seems to be ahead of any other ML-style language, including Haskell. The fact that Idris can compile to those 3 platforms is just huge and those efforts should contributed to.Idris shows immense amount of promise and needs some serious loving from our community.
I'll give an estimate for a usable prototype:
* 1 week to make a Hindley-Milner, strict, functional JVM language
* 3 days to add laziness via InvokeDynamic (requires Java 8)
* 2 days to add type-classes
* 2 days to add a sane FFI
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-function...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
* 1 week to make a Hindley-Milner, strict, functional JVM language
On 19/06/2013 5:22 PM, "Sven Efftinge" <sven.e...@googlemail.com> wrote:
>
> If you really want to support seamless interoperability with legacy Java APIs you *need* to support sub typing. In fact it's best to have as little differences in the type system as possible.
Who says?
> If you want to have even better support for Java APIs than Java, you need to look out for idioms and find way to support them in your language. That is what Xtend does. It let's you write code directly against legacy Java APIs which is much more concise than in any other language. It can be compared to the Scala equivalent when you written and thrown in glue code and implicits.
>
> And it has really cool support for macros and a great IDE!
>
> So a) is done : http://xtend-lang.org :-)
>
--
You received this message because you are subscribed to a topic in the Google Groups "scala-functional" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-functional/kvbaE6cAzqM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-function...@googlegroups.com.
I don't think you want to embed Java's type system directly. What you want is a foreign function interface that is painless to use.
Also don't think I want seamless interoperability with Java APIs. I very much want a seam because calling into Java is unsafe in the general case.