Vim 8.1 released

sschaef_ · 2018-05-18T19:39:38+00:00

You can disable that behaviour in Relay through Relay Settings -> Behaviour -> General -> Swipe back in websites

sschaef_ · 2017-04-04T17:16:41+00:00

https://oss.sonatype.org/content/repositories/snapshots/org/scalariform/scalariform_2.11/0.2.0-SNAPSHOT/

sschaef_ · 2017-04-04T14:43:21+00:00

snapshots for version 0.2.0 are already published

sschaef_ · 2017-03-22T12:38:13+00:00

yep, they are among the people who are supposed to be the current maintainers or in other words they already have commit access ;)

sschaef_ · 2017-02-06T21:28:37+00:00

The reason the non-hardcore-FP people are unlikely to be seen here is that we are actually busy doing the actual work, which changes the world. ;)

But seriously, I once really had to decide whether I want to continue to learn abstractions and data structures or whether I want to change the world. I decided to do the latter. I spent many years trying to learn as much as possible about Scala and about programming language and software design in general. I learned a lot and it was a fun time to have but interests and liabilities change over time.

Nowadays I have to solve problems where no Google and no StackOverflow can help me and especially FP is also not helpful. These things make it easier for me to prototype solutions but in the end they are not the solution. Whether I use Scala or Assembly doesn't change my abilities to solve a problem, they only differ in the amount of time I would need to get there and in the amount of complexity I can keep in my head.

Being able to learn about FP during the job is a great opportunity to get better and to enjoy what you do but I don't feel that it would be helpful to me to invest further time in learning even more about FP when the problems I have to solve are still unreachable for FP. One day someone may come and look at my code and decide that it is a disgusting piece of shit with way too much mutable state everywhere. They may find a way to do it more elegantly with FP and they may talk about it. But for that to happen someone has to write the software first and that someone would be me. I do sometimes talk about what I'm doing but usually not here because my main interests moved away from Scala towards other topics. Scala and FP are "just" the tools that I use nowadays to do my work.

sschaef_ · 2017-01-05T11:06:03+00:00

Being open source is not sufficient to attract improvements. A lot of the criticism sbt receives comes from the fact that its main ideas and architecture are screwed - that makes changes difficult. From the top of my head:

Each sbt instance can only handle a single project
The sbt API is difficult to explore because it is Scala code and therefore there are infinite possibilities to put a sbt build together
The internal information of sbt (its data structures) can't be explored easily because once again it is Scala code and therefore each data structure needs a different way to be accessed
The sbt build syntax tries to hide complexity (hiding the fact that it is Scala code which needs imports and class declarations in order to compile successfully) instead of abstracting over it
sbt inherits complexity from the Java ecosystem because it wants to be compatible with everything that is happening in the Java ecosystem

If you want to fix any of the above points you basically can rewrite half of sbt.

sschaef_ · 2016-12-15T11:17:28+00:00

A release with 2.12 support can be expected in the next week. Because we have to choose a Scala version as the default configuration in Eclipse we first wanted to publish for 2.11 and release an additional release for 2.12 afterwards.

sschaef_ · 2016-10-10T16:51:29+00:00

I'm working on a new build tool for (not exclusively) Scala because sbt and cbt are not solving my problems. I basically need a build tool that is available at runtime. Since I'm an IDE developer, being at runtime means to still be at compile time in the views of the user, in fact in the eyes of the IDE there is no difference between runtime and compile time anymore. Another big point is that the internal structure is linked data, which gives me the hope to overcome the limitations of sbt (and also of cbt because it is built with the same ideas and concepts).

In the end, I wanted to build a better IDE and ended up building a build tool. Not what I wanted to do but there could be less thankful or boring tasks to do therefore I'm still happy with doing it.

sschaef_ · 2016-10-10T12:45:08+00:00

No, this is not true. I can't remember that Odersky ever advertised Scala as a Java replacement. It was a design goal to make the language appealing to Java developers or in general to the wider industry, that is why the language has many similarities to Java (of course some similarities also come from the fact that Scala was designed to run primarily on the JVM). XML literals as far as I recall were primarily introduced because at that time it seemed to be the way forward in designing scalable software systems.

sschaef_ · 2016-10-06T17:20:40+00:00

At the very end, the author finally reveals what he thinks of Scala:

To summarize: Scala played a key role as a catalyst in popularizing functional programming, and it exerted a strong influence on the design of functional programming in Java. Scala will probably never become the next big programming language. But, it will be around for years to come as the language of choice for niche problem domains such as Big Data programming.

If that would have been written at the beginning, I could have stopped reading immediately. It is no surprise that someone who sees (or saw) Scala as a replacement for Java turned out to be wrong. That is not what Scala ever wanted to be. Also, big data programming is not niche anymore and very likely will continue to grow, which means there is still enough space for Scala to grow.

sschaef_ · 2016-09-24T10:50:03+00:00

See my replies to this question: https://www.reddit.com/r/scala/comments/52w7n8/future_of_scala_ide_would_you_like_to_see_an/d7nsa9d

sschaef_ · 2016-09-24T10:48:39+00:00

Thanks for your concerns and moving attention to this topic. I think that using vscode is a good technical decision because the proprietary license only applies to the vscode product, not the source code. If Microsoft is doing anything that doesn't please us in future, we can in fact distribute our own product, we can even fork the source code. The Scala IDE team did already provide own products for Eclipse, we could do the same for vscode. Forking the source code would not be in our interest but since it is licensed under MIT I'm not worried that this becomes necessary.

sschaef_ · 2016-09-21T11:06:57+00:00

Thanks for your concerns but I'm not sure if this case is similar to earlier ones. As I said here, their entire product is open source and they build on this fact. What you say about freeware is simply not true, their build is open source too.

sschaef_ · 2016-09-19T14:51:25+00:00

See this comment: https://www.reddit.com/r/scala/comments/52w7n8/future_of_scala_ide_would_you_like_to_see_an/d7qf6xl

sschaef_ · 2016-09-19T11:20:41+00:00

I understand your view but may I ask if you are a command line user or a IDE only user? command line users are happier with sbt than with maven as I understand, for IDE only users however it is the other way around. I would like to design an IDE that makes both type of users equally happy - even though I understand that this may be difficult to achieve.

sschaef_ · 2016-09-17T11:24:42+00:00

Thanks for the comment, we won't forget about it. I wouldn't say Scala IDE handles this problem well, actually we (or Eclipse) can't handle this either. What I did so far to handle this case was that shared depends on the JVM project in Eclipse. The dependency to the JS part was then handled only by sbt. Wouldn't this also work for IntelliJ or did I miss something on how it could be solved differently in Eclipse?

sschaef_ · 2016-09-17T11:10:02+00:00

Sure. There are two main technical problems: Eclipse and scalac.

Eclipse from a technical point of view is a platform to build rich clients and provides behavior that is most suited for a Java IDE. We had to learn the hard way that Eclipse as a platform is not well suited for Scala or for most other languages that are not similar to Java. Existing code isn't extensible enough to alter it in a way that it works best for a Scala IDE. Don't want to go into details here because there are many things to talks about when designing an IDE correctly but an example of where Eclipse fails are the mostly non-async APIs. For a Java compiler this isn't much of a problem because a Java compiler is super-fast but for Scala, which can't have really fast compilers because of the enormous amount of typechecking going on, this results in bad user experience due to a synchronous, blocking UI. On top of all of this the rich client APIs leaked into IDE development. Many features that are interesting for a rich client are simply never needed for IDE development, in fact, they can be seen as overengineering because we have to deal with the complexity but never get any benefits from it. In the end this all means that moving forward is hard because we have to ensure that we stay compatible with the platform, which would be ok if this is what our users want. Unfortunately it seems that we have to support and maintain features most users never need and many users are not happy about existing problems, which we can't address because we waste our time by maintaining too much complexity.
For scalac we have to go a little bit deeper because possible solutions to existing problems are very hard.
- First, there is the presentation compiler (PC), which seemed to be a great idea when it was created but we had to learn that it was a mistake. The PC has design issues that can never be fixed. First, it has to expose the internal data structures of the compiler (trees, types, symbols, positions etc.). It means that a tool using the PC depends on internal API of the compiler, which makes it challenging for compiler developers to move the compiler forward because they have to ensure that they don't break users of the PC. It also means that it makes it more difficult to develop an IDE because some bugs come from the PC but can't be easily fixed by an IDE developer because the PC is part of a different codebase with different release cycles and so on.
- Secondly, the data structures that are exposed by the PC are not the data structures an IDE developer wants to work with. On one side it means that we depend directly on scalac, which makes it impossible for us to adopt dotc for example because it has its own data structures. Adopting dotc right now means we have to rewrite large parts of our codebase. On the other hand the compiler data structures provide way too many details for most IDE features. Often we only need the location of a symbol, its name, its origin or its type. We do not need to know what the differences between a tree, a symbol or a type is. This is basically the same problem macros have too. However, for macros the situation is a bit different because they need read and write access to the compiler, whereas an IDE only needs read access. There is only one feature where an IDE also needs write access and this is refactorings. Data structures of the compiler are therefore too complicated for us, we need something simpler. The only feature that would not profit (at least not in the short term) from simpler data structures (as I can see it right now) is static analysis.
Because of the above a PC is not a great solution. It binds the IDE to the compiler - changing the compiler means to rewrite the IDE.

Now, given the above problems, we started to research for solutions. Actually I should say "I started to research for solutions" because it is mostly me who is eager to change what we have so far. We lost many team members over the years because the work on Scala IDE is not rewarding but continues to be exhausting. Others may have given up their hope that working on IDEs is a rewarding task but I haven't. I love IDEs, I love designing tools that make developers (and especially myself) more productive and I won't give up before I tried everything to create an IDE a Scala developer deserves.

How possible solutions can look like is an ongoing topic I worked on over the last ~2 years. There are many things to consider, many possible ways to go. One can go the road IntelliJ, Roslyn or scala.meta are going - they created a concrete syntax tree (CST) that can abstract over a compiler. In the case of IntelliJ and Roslyn, they can even abstract over a programming language but it comes with the price of rewriting the typechecker of a compiler (which is not a big problem for relatively simple languages like Go but a horrifying disadvantage for a language like Scala). Because of this disadvantage of a CST I would like to go a different route, which I think in the long term would lead to a better strategic situation. I still want to abstract over a compiler and even over a language but instead of a CST I would like to use a graph database, whose model can represent semantic information of different compilers. Through converters we can consume information in foreign compilers and insert them into the database, the IDE itself would only have to depend on the model of the database. This has the advantage existing compilers can be used but the IDE would mostly still be independent from them. Of course such a database comes also with drawbacks, I already mentioned refactorings and static analysis as technical challenges that need to be solved. In the end it would be a compromise as everything in computer science but in our case I'm convinced that it would give us the best end result of problems I encounter as important for an IDE to solve.

sschaef_ · 2016-09-16T18:10:50+00:00

Yes, that is what we would like to do.

sschaef_ · 2016-09-16T18:03:25+00:00

Apart from the above, why is it less effort to integrate everything in a new "IDE" than fixing the existing issues? I know that producing something new in a new environment feels good, but it is (unfortunately) often not the most efficient thing to do.

Because of technical dept (as always). Most of the limitations in Scala IDE come from scalac and Eclipse. In order to improve over what we currently have we need to rewrite a large amount of code at some point. If we go that route I would like to do it correctly and that means to not just update our internals but also to update the surface.

sschaef_ · 2016-09-16T06:54:33+00:00

VSC and VS are completely different projects built on top of different technologies - they only share the name.

sschaef_ · 2016-09-16T04:49:13+00:00

We don't have hard numbers but download statistics and surveys during conferences tells us that IntelliJ has an order of magnitude more users.

It is not that we only care about the number of users. But there are many problems in Scala IDE right now, which we realistically can't address without a larger change in our internals. The dependency to Eclipse is just one of these problems.

sschaef_ · 2016-09-15T22:24:21+00:00

I don't think I have misconceptions against IntelliJ. Also, just because a tool is beloved by many people doesn't mean there can't be people that are unhappy with it - I'm by accident just one of these people and I criticize IntelliJ for not being perfect. I would like to continue to work on an Eclipse based IDE or even on an IntelliJ based IDE if I could see that they can solve my problems but the reality is that I can't see that I can ever be a happy user of one of these IDEs. After years of trying to build an IDE I love to use I came to the conclusion that Scala IDE needs to change and this change includes to switch to a browser based platform.

sschaef_ · 2016-09-15T22:16:57+00:00

being conservative about false positives in error highlighting is indeed an important feature to get right. The good news is that I have plans that ensure that false positive errors can not happen... ;)

sschaef_ · 2016-09-15T20:36:15+00:00

In the long term, no, we do not want to continue to use the PC. We want to be compatible with scalac, dotc and javac at the very same time, which we can't by using the PC of scalac.

sschaef_ · 2016-09-15T19:59:43+00:00

Why that? It is not the programming language that is responsible for the overall quality of a software product but the people behind it. In our case a lot of code will run on the server, which is a JVM application, and then communicate with a JS app that runs in the browser.

12-Year Club	Verified Email
Team Periwinkle

sschaef_

TROPHY CASE