Daniel Zhang #4
Daniel Zhang #4
Conversation
| Racket as well. Scala also does support pattern matching like Haskell, but it | ||
| seemed slightly more cumbersome. This made it very easy to, for example, return | ||
| different results based on different inputs, as we did in the `matchOnInputType` | ||
| function. It was also very easy to declare variables and use type inference, at |
There was a problem hiding this comment.
I think it's interesting that you mentioned it's both easy to do functional programming and declare variables/type inference. I agree with the sentiment. However, most functional languages make it more cumbersome to declare variables through let statements. It's interesting to try to classify Scala in terms of imperative/functional because it can do both rather well.
| @@ -1,0 +1,51 @@ | |||
| #Scala Thoughts# | |||
|
|
|||
| ###What's easy to do in Scala? What's not?### | |||
|
|
||
| There were a few design choices that I very much appreciated. I appreciated | ||
| the different ways you could use pattern matching. In match/case statements, | ||
| it was possible to include a line like `case x : Int if x > 0`, so that we |
There was a problem hiding this comment.
That's a great point! For me, it was weird at first because pattern matching with a case statement felt foreign. You're right though that it's a very concise way to express the thought and would be harder or at least less concise in most other languages.
| */ | ||
| def roomState(rooms: Map[Int, Option[String]], room: Int): String = { | ||
| error("Fix me") | ||
| if (!rooms.contains(room)) { |
There was a problem hiding this comment.
I did it differently, using .get and pattern matching all the way through. I tried to look online for which was preferred because I had to use case Some(Some("locked")) which seems less elegant than case Some("locked") but did not use an if statement, but I could not find anything. It would be interesting to look more into that.
| */ | ||
| def totalPeopleInRooms(rooms: Map[Int, Option[String]]): Int = { | ||
| error("Fix me") | ||
| rooms.values.foldRight(0)((b,a) => peopleInRoom(b) + a) |
There was a problem hiding this comment.
Similarly, I'm not sure if foldLeft or foldRight is better. When I looked it up, I read (http://stackoverflow.com/questions/24370549/foldleft-v-foldright-does-it-matter) that the performance of the two is comparable because of how Scala implements their foldLeft and foldRight functions. I haven't seen a language like that before
| case i : Int if i > 0 => "A positive integer" | ||
| case p : Person => s"A person with name: ${p.name}" | ||
| case seq : Seq[_] if seq.length > 10 => "Seq with more than 10 elements" | ||
| case v1::v2::tail => s"first: ${v1}, second: ${v2}, rest: ${tail}" |
There was a problem hiding this comment.
I used another if statement here, but this is way more idiomatic. I wasn't able to find this Scala idiom. Good job!
| error("fix me") | ||
| iList match { | ||
| case e1::e2::tail => e1 :: oddElements(tail) | ||
| case e1::Nil => List(e1) |
There was a problem hiding this comment.
This again looks a lot cleaner with the :: idiom. I also didn't realize that there was Nil. This definitely looks way better.
|
|
||
| List(validYoungNames.toList, validOldNames.toList) | ||
| // return the list of just their names | ||
| List(sortedYoung.map(p => p.firstName), sortedOld.map(p => p.firstName)) |
There was a problem hiding this comment.
This looks nice. I also like that Scala can do method chaining, so this can be done in fewer lines as well. It really allows for the programmer to make choices based on their personal style.
| /** | ||
| * Given a string of lowercase letters, ensures that it is a palindrome | ||
| */ | ||
| def isPalindromeHelper(s: String): Boolean = { |
There was a problem hiding this comment.
This is a really interesting way of doing it. I just reversed the strings and output whether or not they were equal, but this definitely works as well.
| familiar with using `myList[0]` instead of `myList(0)` to access the first | ||
| element. I am unsure why the language designers chose this, perhaps because the | ||
| bracket operator has a different use. I also thought that the syntax for naming | ||
| a variable was unusual. I don't understand why `val x: Int = 5` is better than, |
There was a problem hiding this comment.
I definitely agree with this. Personally, it's also very confusing that val and var are one letter apart, so I could definitely see typos causing bugs in the code. I agree that const seems better and would be curious to hear the designers' reasoning.
3 participants
No description provided.