What can make scala more popular?

Is there anything (in Scala, Kotlin, Java, whatever) that fullfills your very obscure requirements? I haven’t seen a single attempt at putting field indexes into a type system. The closest one is HLists but they don’t store field names (so that probably rules them out), just heterogenous types in order. Also emulating field access by traversing such HList would be expensive.

1 Like

Could you explain what is the motivation of the question. Is it necessary that a feature would exist in another language? I remember the time when scala was the first. White box macros can help.

No, it’s not necessary, but so far there isn’t even a clear direction. You haven’t even shown a full theoretical example with your desired syntax and how would it desugar to a working example in conventional Scala.

I have an impression that if you try too hard to make super-flexible mechanism then you’ll end up with something costly anyway. Records in Dotty https://github.com/lampepfl/dotty-feature-requests/issues/8 look like plenty of class casts and megamorphic calls in addition to a new HList instance created for every new row.

But again, it’s hard to optimize for use case that is not fully known. Show the actual working code and tell where is the redundancy that you would want to avoid.

2 Likes

OK, it is clear. I will try to create more detailed topic later. It is not easy task for me. I just do not know whether something is difficult or not. The main idea:

  • it should be array or product after compilation in bytecode
  • Scala should allow to use name instead index in code
  • The dinamics is allowed for whole dataset instead of each row.
  • it should be very usefull in such library like slick :slight_smile:

See: Discussion about structural types(Flyweight pattern)

Is there anything (in Scala, Kotlin, Java, whatever) that fullfills your very obscure requirements? I haven’t seen a single attempt at putting field indexes into a type system.

Yeah, there is at least Haskell superrecord library - SuperRecord: Anonymous Records for Haskell that morphs morphs labels to indices. SML#, according to stackoverflow, uses implicits to pass indexes for polymorphic records - Why doesn't OCaml support record subtyping? - Stack Overflow
Also, so far all discussed implementations of structural types for Haskell in https://github.com/ghc-proposals/ghc-proposals/pull/180 are index-based, not hashmap-based.

However, all of the above are for row types without subtyping, I’m not aware of any implementation of index-based access for subtyped structural types.

1 Like

Thank you. Before these links I felt very confused. Now, I know, There are people which solve such tasks. :slight_smile:

Since @AMatveev created topic Discussion about structural types(Flyweight pattern) we should use it for discussion about index-based record types. I have no clue why the topic name is so weird. What has “flyweight pattern” to do with index-based record types?

2 Likes

I really respect your stance.

Nevertheless it is too hard joke.
For example, sql is turing complete and it is functional. many people use other languages only because of mutability. :slight_smile:
And scala can not be better java if it fights against mutability :slight_smile:

Hmm. That’s an interesting assertion - it’s true that many languages are mutable, but I don’t know that there is much evidence that they are popular specifically because of mutability. I’d say that they are popular because they are easy. Which may be somewhat related (since most people learn mutable styles first, it’s easier for them to pick up), but isn’t the same thing …

2 Likes

Sorry, I have not said that popularity of any language depends on mutability, or simplicity. I think it is not the main point.

But I cannot imagine popular procedural language without mutability also :wink:

To say the truth I think the joke was around the words:

I sure that immutability of scala is butifull thing. But I think it will not good if it is the only killer feature. And if a procedural language does not have comfortable mutability it is not very good. I really like calling card like if you need big data processing the scala is for you. You will get mutability, immutability, object, fast record,macros. All what you need to quickly make fast reliable business app of any scale. I think it is more business oriented approach. :slight_smile:

1 Like

Making a language that is a kitchen sink of syntax features is not business friendly, I think. Look at C++ - it has everything and even more things are coming in next editions! You can write low-level code, high-level code, OOP code, functional code and even dysfunctional code. Only the last aspect was implemented properly :] How does C++ fare? Its significance diminishes. Less and less people want to deal with the absurdity of language complexity. Therefore we need to constraint the choices somewhat.

Scala community is already divided between two high-level programmers groups - pure FP ones and mixed OOP+FP ones. Adding low-level imperative coding lovers as a third group would mean even more division inside of Scala community. Do we want that? I don’t.

Big data, AI. machine learning and a lot of latest hot stuff (no matter how much sense it makes) is implemented in Python, which is a really slow language if you go through the route of writing pure Python code. If you want acceptable performance you need to find C libraries and write glue code in Python instead of writing real algorithms in Python. Scala is already much better than Python, performance wise.

Scala has mutability and will keep it. It’s just that mutability is second-class concern. Most of the time you should stick to functional programming.

Scala was never meant to be “better Java” (whatever that means). It’s not hard to find what Scala goals are. Look at Scala’s front page https://www.scala-lang.org/ :

There’s nothing about crazy mutations and low-level code. In fact it’s totally the opposite. Scroll down for “Online Courses” - you’ll see introduction to functional programming in Scala (totally non-imperative programming). Look at Scala conferences agendas - they are full of functional solutions to programming problems. It’s not surprising that when people hear “Scala” they think “functional programming on JVM” and not “extra sugar for Javaisms”.

In fact, if you look for “better Java” then two languages come to mind (three if you consider future Java to be another language than today’s Java):

  • C# which is touted as “Java done right” by C# programmers (that’s probably half-trolling, half-taking-pride) - C# wins the race of having the most keywords in a programming language
  • Kotlin which is designed to have a smooth learning curve for Java programmers and low friction integration with Java libraries and frameworks
  • Java itself is also developing, there are lambdas in Java 8, type inference (vars) in Java 10, future plans include pattern matching and data classes (counterpart of case classes)

So the competition is already tough. Scala is rather problematic if you compare it to the languages above. Scala breaks binary compatibility between versions (i.e. every two years or even more often), still has relatively slow compilation speed, has incompatible collections (so many frameworks and magical reflection-based libraries need special support for Scala). It would be hard to sell Scala as Java with extra syntactic sugar given these disadvantages.

Also, it seems to me it would be easier and more sensible to port the few Scala features you like to Kotlin than port the many Kotlin features you like to Scala. It’s really weird that you want to make Scala a Kotlin clone instead of just moving from Scala to Kotlin.

4 Likes

It is very doubtful analogy. It seems that its because of my words. But I can not see any connection. I like holy wars about c VS c++ but here is forum about scala… And I can repeat it for most other statement. I can make symmetric answer at least

Let me answer in same manner. I’ll be brief.

  • I feel tendency to isolation in last message.
    It seems there is nothing good in the sacrifice some language feature because of beautiful words.

If C++ is not an acceptable example then maybe Perl? Anyway, Scala should learn from mistakes of other languages. As the famous saying goes: “Those who cannot remember the past are condemned to repeat it.”

If something is added then removing it is problematic. That’s why most programming languages evolve rather slowly. Otherwise you end up with bloated language. Another example of such thing is C# - it has plenty of keywords and small language features. Even C# fanboys are complaining already that the language is too complex for too little gain.

In the end it seems that either there are people who complain loudly that there are too few features or there are people who complain that there are too many features in a programming language (so they choose simpler ones instead). There’s no silver bullet to that. You can never create a language that you can sell to everyone at the same time.

2 Likes

It is very beautiful words until sombody say it to you…
See also:
https://www.scala-lang.org/blog/2019/05/02/community.html

I like such philosophi. there is something kind there.

AFAIR this is a response to a drama which caused some threads here to be closed. Do you want this thread to be closed too?

No I do not. It seems we are in different camps. Where you see disadvantages I see opportunities.

Martin’s words.
I see this difference of approaches as a big opportunity. There are so many great ideas to debate and opportunities to learn from each other!

1 Like

The next line after your quote is key:

Lots of these ideas feed into the design of Scala 3, with the overall goal to make Scala’s integration of paradigms even tighter than it is now, as well as making it simpler and safer.

While discussing stuff like adding syntax to ease working with mutable data certainly shouldn’t be banned, not everything is going to be adopted.

The SIP process is the primary filter, as far as I understand it, but I’d be really surprised if the support for the kinds of additional features you’re advocating make it in, as rampant mutable state doesn’t really tend to go hand-in-hand with safety and simplicity.

1 Like

This is a very General statement. I think it would be better to use more constructive arguments, you can give a reference to the feature at least. I agree with all your words in general completely. But to tell the truth I disagree with micro aggression and provocation to holywar.

1 Like