Reviewing and, possibly, Revising the Core Path

[Stargator]

@jvarness @devkabiir Are there any exercises remaining, or that we implemented from the list, that you think would make for good core exercises?

To me a core exercise should:
A) Build off of the previous core exercises
B) Either solve a problem by 1) using the same mechanism as before but in a new way or 2) presenting a new kind of problem.

For example devkabiir's work on Minesweeper and Binary Search Tree, these are new kinds of problems but may contain previous lessons from core exercises.

All of our core exercises should be building towards getting students ready for those kinds of problems which are complex and involve multiple types of problems to solve a big problem.

But I don't know if either of you have a different perspective we've never written up a definition or direction for the core path.

Originally posted by @Stargator in #149 (comment)

[jvarness]

Much of our current track deals with much of Dart's core functionality that is common to a lot of other languages.

I think we need to try to figure out some potential problems that can be solved using (in order of what I think are more important to less important to add):

• Futures and Streams
• Cascades
• Generics
• Pure functions
• Named Constructors
• Interfaces/Mixins

I think I might try to take a stab at defining what the core path might look like soon.

[Stargator]

@jvarness When you do that, also look at what is currently being introduced (like exception_handling) whether directly via the tests requiring the implementation of it or whether it is just there in the test suite (like multiple groups or distinct functions for a group of tests) without requiring the user use it in their solution.

The focus should be on the language (ie: the SDK) and not rely on any third-party packages or the configuration files (pubspec.yaml, dart_test.yaml, etc)

[jvarness]

Right, of course, no packages other than what's built into the Dart SDK

[devkabiir]

Hi @Stargator , @jvarness. Here are my 2 cents.

• Futures and Stream
• Pure functions
• Interfaces/Mixins
• Generics

These are language independent concepts/patterns. They exists in other languages, I think these should be our priority. Chances are high they are the most commonly known to learners or if not most useful in their careers in Dart or programming in general.

• Cascades
• Named Constructors

While these are more like exposure to Dart's syntax. We can sneak in these once in a while here and there. Perhaps in hints/tips section of readmes. Because static methods can take place of named constructors without the caller required to make any changes. There isn't a way to write tests for them. But there can be hints about them. For instance static methods can have generic type parameters while factories and constructors can't. It's also a common pattern to have abstract classes with factory methods that returns an implementation based on method parameters.

Language spec

Here's a link to Dart 2.2 Spec PDF.

We can take the spec as a reference on what parts of the language to focus on next.

For instances

• Type promotion
• Type Aliases
• Difference between dynamic and Object
• Difference between void and null
• Difference between Null and null
• Strongly typed vs Soundness
• Dart library vs Dart script
• Dart library vs Pub package
• Keyword this, used to access current instance. Leaners coming from JavaScript background will appreciate this.

While these concepts exist in other languages. They certainly aren't implemented the same way in dart. I know these are basic on the surface but certainly worth focusing on.

Meta-programming in dart

This is a powerful concept to know. Dart has some support for it. More in the pipeline. Not sure how this can or should introduced.

Core path

But I don't know if either of you have a different perspective we've never written up a definition or direction for the core path.

I do have a proposal for that. Looking at the Language spec, we can see from the TOC the path they've taken. I used that as an inspiration.

 - Basics
    - Variables
    - Expressions
    - Statements
    - Functions
 - Intermediate
    - Types
    - Classes
    - Enums <-- I'm sure we've exercises that cover at least this much part of the language.
    - Interfaces
 - Advanced
    - Generics
    - Mixins
    - Sync and Async programming
    - Metadata (Meta programming)
 - Libraries and Scrips
    - Import
    - Export
    - Parts
    - SDK usage
    - External packages

The actual implemented path doesn't have to follow the exact hierarchy. This path is specific to Dart language. The path does not take into account any best practices, patterns, data structures, algorithms. It tries to explain how a learner might do a certain thing in dart and that's about it. But due to the nature of exercism exercises, they tend
to introduce a concept from programming along with something from the language track.

In conclusion I think we can start the discussion from Interfaces level of path. And assign one or more exercises to a topic. While the exercise itself might also cover a topic from exercism's list of topics. I'm sure once we've exercises assigned to all the topics we will have covered most of what there is to learn about Dart.

P.S. I have an errand to run so I might update this comment again with more of my thoughts.

Edit:

Dart is a general purpose language. It's used to write command line apps, server-side apps, web-apps, mobile-apps, etc. Which might be one of the reasons the learner is doing this track. Doing cli, server, and web should be possible without any external packages. We could create track-specific exercises that show these capabilities.

For example we could have an exercise for cli. That covers taking arguments from cli and outputting on cli. Perhaps some async task on cli such as create a file of name taken from first argument and write Hello World in it.

For web exercise, use streams to fetch large data or stream of keyboard events.

For server exercise, listen on port 8080 and reply with hello $name when posted to /greet.

We can have exercises in these areas which can cover a lot of the advanced topics as well.

[Stargator]

@devkabiir and @jvarness Thanks for the responses

Dinesh, I largely agree with you. But from a practical perspective, we need someone to do a review of the existing exercises (and any incoming PRs) to see which of the topics in Basics and Intermediate any of them require or utilize.

The only way for any In order for exercises to require the use of these concepts via the test suite. For example, for named parameters we should call a function using named parameters which would result in the student's solution having a function that fits that need.

As far as Interfaces and Generics, that would require that we have specific cases for those objects, which I would be fine with as long as the README discusses that.

[Stargator]

@exercism/dart I think we can apply a lot to the efforts to setup v3 of the dart track. Any changes related to this, should be made to the dart section of https://github.com/exercism/v3

[Stargator]

@exercism/dart Given that the Concept exercises being created for v3, that means any discussion of "core path" is overtaken that what work. Each concept exercise would be built around a single concept or aspect of a larger concept.

I'm closing this, but will link to this discussion from the v3 repo