Earlier quoted context omitted.
IMHO, libraries like this should always have an easy "out", where the default is strongly typed, but the user of the library can explicitly escape the known behavior if need be. As a (albeit poor example), I once inherited a click tracking system that uses Java Jersey. The standard response object has a .redirect(URI uri) method. Unfortunately, many "URI"s we receive from the world are not actually value, and the jav…
At present, in rust-http, invalid values will be dropped; that will be changing so that you can retrieve a bad header value ( https://github.com/chris-morgan/rust-http/issues/27 ). Writing invalid HTTP, on the other hand, is something that I'm in two minds about. You shouldn't be allowed to do it, but it may be necessary somewhere along the way. At present, you can write invalid headers through the use of the extensi…
Scala – 1 Star – Would Not Program Again
61–70 of 324 posts
Re: Scala – 1 Star – Would Not Program Again
#62Earlier quoted context omitted.
I've been wondering - having never used a web framework except for some RoR - what people miss in the idiomatic Clojure way of doing web (composing libraries like Ring, Compojure, Enlive etc). Care to share?
Honestly I haven't used Ring/Compojure/Enlive beyond tutorials so at this point I'm very intrigued but don't have much to say yet. My belief though is that there is some peace of mind that comes from the idea of what you might call "page composition" -- that this piece of data sits in this template, that it rides on top of this simple model, that it is in ORM from database. There is a huge amount of linearity and con…
> My belief though is that there is some peace of mind that comes from the
> idea of what you might call "page composition" -- that this piece of data
> sits in this template, that it rides on top of this simple model, that it
> is in ORM from database. There is a huge amount of linearity and convention
> throughout the stack and because of the dynamic nature of Ruby lots of gems
> can be sprinkled throughout without one really understanding what they do.
Actually, the problem with OO and my experience with Rails is this linearity quickly becomes a web where deriving the sequence of events encompasses more and more of your time as the project grows.Objects call objects across the system and change the state of each other without care. Making a trivial change involves unrolling this web every time.
And that's why I think you have this backwards:
> Now, I'm certain this level of abstraction and functional/mixin kindof stuff can be
> achieved in a Clojure framework but I think it is generally perceived as being a bit
> more non-linear and DIY (libraries not necessarily playing nicely together). As in
> "yes I can get all of these pieces together but then if down the line I have to change
> this piece, how will I accomplish it without breaking everything".
`require`ing a Ruby gem is as non-linear as you can get. It's global with no entry-point. A gem's presence and effects are not obvious. They're often configured with some mutation like: MyGem.config do |c|
c.key = "secret"
end
Meanwhile, it's obvious when a namespace of Clojure functions is included. And since they're just functions, they're trivial to compose. Completely different experience from what I was used to in Ruby.Re: Scala – 1 Star – Would Not Program Again
#63Earlier quoted context omitted.
I've been wondering - having never used a web framework except for some RoR - what people miss in the idiomatic Clojure way of doing web (composing libraries like Ring, Compojure, Enlive etc). Care to share?
I was a full-time Rails developer until a crescendo of disillusionment finally cajoled me to learn Clojure. I don't really know that I miss anything. The things I might've thought I'd miss are the things that ended up souring the taste of Rails. Having to come up with my own abstractions or recreate familiar conventions or set up a database were areas where I had to cut my teeth, but I also had to cut my teeth on Rai…
Would be interesting to see a blog post demo'ing your workflow.
Re: Scala – 1 Star – Would Not Program Again
#64Re: Scala – 1 Star – Would Not Program Again
#65But once haircut fascination is over - people expect you to do mundane tasks, like cook food or take out the garbage. Or they won't pay you.
And then you realize that when Scala cannot do what you want - you can always revert to Java.
And then you realize that you don't really need Scala-ing if you can do the same stuff in Java or any other strongly typed language.
Re: Scala – 1 Star – Would Not Program Again
#66Scala can be summed up in one issue. http://play.lighthouseapp.com/projects/82401/tickets/98 I loved Play 1.x(early adopter also) but I have since moved on. I gave Play 2 a solid chance. Scala programmers seem to turn everything into some kind of academic paper.
Re: Scala – 1 Star – Would Not Program Again
#67Earlier quoted context omitted.
And with Groovy as a scripting layer, it's more than fine. Quite good in fact.
Is Grails as good as they say it is?
It's also a pleasure to program in Groovy.
Re: Scala – 1 Star – Would Not Program Again
#68To be honest with you, I use Scala as a better Java. Which means I still code imperatively (and use null instead of None) but with less noise (semi colons etc). But, esp when working with collections, I take advantage of Scala's features. It's not perfect, but it works wonderfully. I can always revisit/refactor my code again later.
You might be better off using a pre-release snapshot of Java 8 as a better Java. You'll get closures, functional collections, and better type inference. I bet Eclipse and Intellij support it better too.
Things I have in Scala that I like and Java 8 won't provide (many are syntactic sugars and non critical stuff, I know, but I like it, I'm spoiled)
- implicit conversions. some hate it, I love it. It allows much better "pimp my library" mechanism than Ruby's and it's very easy to write extensions to your or 3rd party extensions in a safe and easy manner
- duck typing, e.g. allows to write a "try with resource" without native support for anything that implements "close"
- automatic tuples
- better type inference
- semicolons, hate them
- automatic equals and hashcode for case classes
- case classes
- futures and promises
- by name parameter passing (passing a block of code without running it)
- partial functions, multiple parameter lists
- for comprehensions
- pattern matching
- nested functions
- lazy vals
- everything is an expression
- String interpolation
- multiline string
- default parameters
- named parameters
- pattern matching
- everything is immutable by default
- very string type system
I think that's it. Yes, Scala is infamous as the language that took many many features from other languages and piled it all together, well, fine with me! you say more features that are great in other languages and make people productive? (and are kind of expected, like default parameters etc) I say bring them on and the more the merrier. I can choose which features I want to use out of the way too many features the languages, much better than waiting years for features to be added. Hater's gonna hate, I'm still going to write Scala until something better comes around. (Nimrod? Kotlin? Ceylon? TypeScript? Dart? perhaps even Go? Don't know... time will tell)
Re: Scala – 1 Star – Would Not Program Again
#69I'm always interested to see intelligent criticisms of one of my choice languages. Let's take a look at what he has to say: Slow build times complaint > It is essentially impossible to practice TDD in Scala simply due to the time it takes to compile. Hrmm, that's interesting, because it sure seems like other people are able to do this. I agree, the slow build times are annoying, but let's not exaggerate. SBT critique…
Re: Scala – 1 Star – Would Not Program Again
#70I think Scala is great as long as you stay on the road and not end up in the deep depths of academic hell (i.e. http://blogs.atlassian.com/2013/01/covariance-and-contravari... ). I should say one thing however: I'm using Scala because of Akka. An extremely powerful library that does a good job of hiding the complexities while still allowing you to be flexible.
That's a gratuitously category-theoretic explanation, all you need to explain covariance and contravariance is is-a. An immutable List of Foos is a List of Bars if a Foo is a Bar. A function taking X and returning Y is a function taking A and returning B if A is a X and Y is a B. It's just answering the question "Can I use type relationships to guarantee that I will have no run-time conversion failures?"