Why not? Seriously: in a language with reasonably good type inference, I don’t see any good reason why it should be any worse for this purpose than any other language. And Ammonite serves as a pretty good proof of concept…
I think it is possible because we already have something that does it, namely Ammonite!
I just showed a roughly equivalent example in Python and Scala. If you nonetheless prefer to use Python or whatever, that’s fine! But don’t derail the conversation of people who know how to and do use Scala for the same things, to good effect, and would like to make it more inviting for others.
Having done non-trivial automation with bash, I can tell you that recompilation is much better than having it fail at runtime because of a typo in an uncommon execution path.
I’m not as familiar with Ammonite as it sounds like I should be. Having it blessed would go a long way towards making it easier to defend using it to replace those scripts that have progressed into the awkward territory of having grown beyond bash and not yet to the point of justifying a rewrite in Scala+SBT.
Yes It is really good.
Seriously It is very painful question.
I remember we have discussed what to use for dynamic expression instead of plsql. And of course the first thing we have tried is
- the performance is awful (I do not remember it is 10-100 times slower)
- the memory usage is terrible
We have currently so much troubles with hot updates and binary compatibility which just doesn’t exist in dynamic type languages.
So I just do not believe in scala scripting in general.
It is very good until you do have binary incompatibility hell.
Sorry, if you would like to compare python and Ammonite I wish you good luck.
I hope that someday Ammonite will be more popular in scripting.
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.
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.
Except real people mostly don’t behave like this.
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 (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.
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
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.
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.
It seems you are right and I have made some off topic. I am sorry.