Proposal: Simplifying the Scala getting started experience

This is an advanced use case. It’s not relevant to the getting started / non-language-expert scenario we’re talking about here.

It is true that interpreted languages tend to be able to evaluate expressions (once) very fast, faster than a compile-execute cycle. But for the scenarios we’re talking about nobody cares about that level of overhead; it’s swamped by the time to type your few-line script.

This is also an advanced use case, and thus also not relevant. (It’s also wrong-in-spirit because you exchange avoidable (if you recompile instead of just relinking) bincompat problems with unavoidable runtime crashes, but there can be cases where bincompat fails but source compatibility is okay and maybe you have a lot of these. Anyway, it doesn’t matter how accurate the observation is because it’s not the use case we’re thinking about.)

Sorry I have understood that that you are not talking about it from your previous message.
I just do not want to continue discussion with such argumentation quality.

You think that it does not matter.
Ok, it is clear.

Excuse me for my question.

All this talk of simplifying things is great. But I think the formula is Effort = Complexity X DiscoveryEffort, meaning to say, if something takes 1 step but you have to dig through 5 cryptic pages of documentation to figure out what that step is, you might be worse off than with something that takes 10 steps, each of which is governed by multiple absurd rules, but there is a single page, at hand when you need it, written in very readable English, that walks you through exactly what to do. (Obviously both are exaggerated nightmare scenarios, I’m just trying to explain what I mean by those two variables.) So again, not to minimize any of this, especially since simplifying things also reduces the amount of documentation needed… but let’s not forget that another important factor is how easy to find and easy to read the documentation is.

1 Like

It is good to think about effort. But there is another very important question.
It is profit. So we have motivation = profit / Effort
Ok, I have done it and what is it next?
For example it is very easy to open scala online and write “hello word”.
But there are no real profit in everyday life because it do not solve everyday tasks.

So I think there are no sence to do very simple examples which have no practical proffit.

So making simple sbt project is relatively hard. But this can help you to start real project at least if you really need it.

Except real people mostly don’t behave like this. They go for a whole series of least-resistance steps. If they can’t find the documentation, or if it doesn’t work the first or second time, or if they have to type boilerplate, or if they don’t get an instant pat on the back, they walk away and don’t do it at all or do it in python or js.

The point of making println("Hi Mum") zero boilerplate isn’t that it has utility. It’s that it gives users an instant reward. They have got the computer to do something.

1 Like

Except real people mostly don’t behave like this.

IMHO
May be you are right.

But for me a language is like a tool. if I have a task I will take appropriate tool whether it is pliers or a screwdriver it depends on a task.
I just have noticed that it may be impossible to make a good\simple hammer from pliers.

If you really enjoy such things ok, just do it.
But I think
if a pro does such things it can be very beautiful. But when you teach such things students it can be the way to really big dissapointments.
I have seen many such disappointments.
I do not think such simplicity is very good, but if somebody like it it is not my deal after all.

What I really dream about it is a mode which allow to write right scripts in scala.

  • When you just do not need a build system at all
  • where there are no binary incompatibility problem.
  • When a single error in some unimportant file do not stop compilation at all.
  • when you can simply call a method to usual scala code

It is a real key to simplicity :wink: (when all you need is vi editor and installed package)

it would be cool if there were a real simple scripts. There were a real big communities on such tasks and so on.

1 Like

A language is easy to learn if it is governed by simple rules.

For example, “All code resides in methods, and all methods are part of an object” is a simple rule.

If you enable one-line apps but complicate the rules, you are not helping beginners.

Have you asked casual beginners about that?

Turning Scala into a duck-typed language will obviously fail. It would be analogous to turning Python into strongly typed language that rejects programs with type errors. Scala compiler depends a lot on types, for example all implicits are type driven. Scala without types would be a very different language.

Scala scripting is not about fundamentally changing the language, but rather removing the need for structuring source code within a file, and files within a project. You can do scripting in strongly typed languages like Java (JShell), C# (PowerShell), Scala (non-standardized yet?) and so on.

Performance and memory usage have lower priority than developer friendliness and productivity when it comes to scripting. Python has low performance and high memory usage, but it’s (the most?) popular language for beginners simply because you can finish the task sooner.

In general Scala is a bad language for scripting because of high compilation overhead, so insisting on using Scala scripting in e.g. production wouldn’t be sensible. Instead Scala scripting should be oriented towards beginners (who only start to explore Scala), to make Scala more popular. Scala doesn’t need to be a language for everything.

It is just a dream . But there are nothing imposible. For example, scalajs is certainly dynamic typed.

It’s that it gives users an instant reward.

programming is not a drug :wink:

Actually compilation overhead is very important in dynamic evaluation. So, we cannot use groovy for that purpose either.
But groovy is very good in some web framework in the area where dynamic is more important than runtime speed.

We also have areas where I would prefer to use groovy if I had no scala controllers.

IMHO

Really I do not understand the desire to advertise scala in the area where scala is really weak. I think it is a bad publicity stunt

It is not.

@AMatveev I think you have sufficiently made your point. Yet apparently most other participants in this thread disagree with you. Please respect that take that into account.

To everyone: this discussion needs to be refocused on the initial topic of how to improve the getting started experience, instead of whether we should even care about the getting started experience.

1 Like

Ok, may be I have used bad terms, but it is over javascript so it should use “dynamic invocation”.

It seems you are right and I have made some off topic. I am sorry.

I’m not sure what is a casual beginner. I have had team mates over time with very little coding experience who often asked me for help. Does that count?

1 Like

So let’s define one low-experience, casual coding group as people who can write an excel formula. They can enter numbers into cells, and enter formulas in other cells to compute derived values. But perhaps haven’t yet done any excel macros.

Let’s define another group as undergraduate students with no prior coding experience on day 1 of their programming practical. This first prac will inform their view of if coding is for them or not, and if that language in the lab is difficult or not.

And lastly, lets’s think of somebody who once a month or so has to generate a report from some data, and for that day writes some throw-away python scripts small enough to fit on a screen without scrolling. They forget most of what they know between each scripting day, and have to in effect mostly relearn it each time.

Let’s see how a hello-world looks like in the most popular programming languages.

I’m not an expert in judging what are popular languages, but I’ve heard people referring to the TIOBE index in the past, which currently starts with (1) Java (2) C (3) Python (4) C++ (5) Visual Basic .NET (6) C# (7) JavaScript (8) PHP (9) SQL (10) Objective-C

It doesn’t exactly confirm the hypothesis that short hello world programs make a language popular.

= = = (1) Java = = =

public class HelloWorld {
public static void main(String[] args) {
System.out.println(“Hello, World”);
}
}

= = = (2) C = = =

#include <stdio.h>
int main()
{
printf(“Hello, World!”);
return 0;
}

= = = (3) Python = = =

print(“Hello, World!”)

= = = (4) C++ = = =

#include

using namespace std;
int main()

{

** cout << “Hello World!”;
return 0;**

}

= = = (5) Visual Basic .NET = = =

Imports System
Public Module Hello
Public Sub Main( )
Console.WriteLine(“hello, world”)
End Sub
End Module

= = = (6) C# = = =

using System;
namespace HelloWorld
{
class Hello
{
static void Main()
{
Console.WriteLine(“Hello World!”);
}
}
}

= = = (7) JavaScript = = =

alert( ‘Hello, world!’ );

= = = (8) PHP = = =

echo “Hello World!”;

= = = (9) SQL = = =

BEGIN
dbms_output.put_line (‘Hello World…’);
END:
/

= = = (10) Objective-C = = =

#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSLog(@“Hello, World!”);
}
return 0;
}

Cool. And of those, people who code who aren’t coders write python, js and php.

Ok, I’m imagining an Excel user. Why would they even code anything, if not macros?

To the undergrad student on their first day of coding ever - does it really matter that much to them whether their first app is one line of six lines? Beginners rarely complain about boilerplate, it’s usually the advanced users after they had to write it a hundred times.

It is usually the experienced coder who writes code to process data. Others import their data into Excel.

This is going to be my last reply on this topic. I want as many people as possible to use scala, from people engineering critical business components through to people who write a bit of code half way through working through their end of year accounts, and I want as few people as possible to be put off from using scala when they first try it out. I’ve watched people walk away from coding before they even really start because their first experience involved barriers to entry. And I’ve seen people take to it right away because they could type a sum into the javascript console in their browser, and right away get the computer to do fun things. You get casual adoption by making the casual experience rewarding. That means getting rid of everything you can that delays gratification or gives an opportunity for mistyping boilerplate to make it fail.

4 Likes