I know this is not the programming languages weblog but I'll still
like to chip in a bit..
I love Scala. I know it's confusing, sometimes (more often than not)
it makes my head hurts. But the language itself is so expressive. I
think it's kinda, well, maybe I'm machoistic, but there's often
instances when I run through a hard to understand Scala code and it
just struck me how concise the language is. I'm a relatively n00b
programmer, probably 5 to 7 years coding and most of them dealing with
c, php and all sorts of c spawn in various shallow degree, and at my
work I deal with Java, JavaScript and ActionScript. For me, the first
impression of Scala is that it far exceeds the awesomeness of JS
coding. I think JavaScript is really a very nice scripting language,
but there are certain quirks that makes it feel inadequate at times.
But Scala eliminates them, and adds in static typing, which is like
awesome. And well, far too many underscores.
I think a good mature language is poetic, which I find Scala kinda do
fit this criteria. When you read through a difficult routine you think
"wow, this is clever", instead of times when I read C code and go like
"wow, this is tedious" because a big portion of code ends up dealing
with lower level problems. I know it's not comparable because the
compiler abstracts out stuff, but speaking on a pure philosophical
level, I just like it how the language allows you to do clever things.
Unlike Java *sigh*.
As for lift, I find some things very interesting, and mainly there is
a big shift from the traditional php based or Java based frameworks (I
worked on Drupal before, while not exactly the same stuff, but). I get
the crux of it already, and am moving along and reading code as I go
along. The use of snippets as opposed to a monolithic C layer struck
me as odd, and xml spewing in snippets does feel a little wrong (oh
the darn mvc brainwashing). But overall I like what I see and hope to
do something useful with it. Will comment as I move in more.
Thanks for the good job guys. I think it's Scala and Lift at this
point of time that keeps my computing life exciting. Keep up the good
work.
regards,
CH
On Oct 23, 6:06 am, Ross Mellgren <dri...@gmail.com> wrote:
> Personally I think that Python is great for small simple things, but
> as soon as you start to scale the lack of statically checked
> guarantees starts to bite you. The larger and larger you get the more
> often and more subtle the bites get. Conversely, with a rigorous
> statically checked language, you can start to use the static checking
> in your favor. And, the more you understand the nuances of the type
> system the more and more you can form it to give you even stronger and
> stronger guarantees.
> Anecdotally, Haskell (which is perhaps one of the most advanced
> functional programming languages on the planet, particularly in the
> type system department) has regular reports in the mailing list from
> newbies that usually go from "wtf" to "whenever I get the compiler to
> accept my program, it usually just works" in a fairly short time.
> The syntax of Scala is an interesting and convoluted beast straddling
> an unusual line between more typical functional programming languages
> (Haskell, O'Caml, etc) and Java, and overall I think it ends up doing
> a fairly good job, though it does have its confusing parts.
> The ability to define operators in particular is a very tricky
> subject. I find, along with implicits, that I treat it as a power tool
> that should only be used in cases where it really makes quite alot of
> sense (used extremely frequently, coming from math concepts, etc).
> Luckily, it is fairly easy to find out where operators are coming from
> -- if it looks like an operator, then check to see if it has a :
> (colon), if it does, the thing on the right is where the operator is
> defined, so look in its doc. Otherwise, it's the thing on the left
> that has the operator, so look there.
> If neither place has the operator, then unfortunately you've just
> strayed into implicit conversion territory, which is unfortunately
> tricky to track down in many cases. Sometimes in that situation the
> scala REPL will help, because it prints out the types of expressions.
> Coming from a background of knowing Java and Haskell (along with
> Python and many other languages, not apropos to this discussion) I
> found the syntax of Scala to initially be inscrutable but I warmed to
> it after a month or two and now I think it's pretty good.
> Regarding () and {} BTW, you can replace a single-argument argument
> list with {}, e.g.
> def myFunction(a: String): Unit = println(a)
> myFunction("foobar")
> myFunction { "foobar" }
> The two calls are equivalent. It makes more sense with the latter
> format with multiple argument lists or DSL-like things. I could write
> up an example if you're interested, but it might be somewhat involved
> if you're not familiar with Scala or Lift.
> Overall, my suggestion would be to stick with it and ask questions. I
> think it's worth it, and the people here are really helpful.
> -Ross
> On Oct 22, 2009, at 5:39 PM, jlist9 wrote:
> > Just want to add to this. web.py is a Python web development framework
> > that I like a lot, for its simplicity. In about 10 lines of code you
> > can have
> > a complete, albeit simple, web application. No XML whatsoever.
> > Hope no one is offended by my mentioning a Python web framework on
> > Lift list. Just want to say that things can be short and simple as
> > well
> > as easy to understand and easy to use.
> > Of course the dynamic languages have their known issues, which is
> > what drives me to Scala and Lift.
> >> And too few operators leads to a whole lot of words, which leads to
> >> a whole
> >> lot of typing, or a whole lot of ctrl-space completions. It's a
> >> toss up.
> >> The wordy way is definitely noob friendly, while the operator way
> >> is more
> >> expert friendly.
> >> Which do you design a language for? Let me know when that particular
> >> religious war dies down please.
> >> As someone who slings code for a living.... the less I type the
> >> happier I
> >> am..... YMMV
How hard can automatic save be?
But how would immutable DAOs work? There was a thread, I think on scala-user, a long time ago discussing it, that pretty much concluded it would be very problematic. David weighed in and said after a long time he concluded that databases represent state.
I kinda wondered why you haven't pushed forward any more with the
current record implementation... can one assume that is why - because
it didn't feel right?
Some of this stuff is going to be fundamental to how we move forward -
id love to perhaps discuss something that would be better than what we
have already. Even if its just pie in the sky talk...
> I don't like mutable fields. I don't like manual saving. Dunno...
> it's hard to articulate... it just feels wrong in my tummy. Also, I
> want to be clear that I think Marius did a great job of cleaning up
> some of the problems with Mapper when he did Record... my comments
> are not a negative to him... there's just something unsatisfying
> about the whole approach.
The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?.
funny, I had stumbled on exactly the same line of code when beginning.
Took me more than a day to understand what's going on. Especially
because when you copied code from the PDF version of the Liftbook/Lift
getting started guide, it would mess up spaces, so I would keep
loooking for a "_::" operator.
The Scala guys have really pushed it a bit hard on the use of the
underscore. At least four different uses:
- "it" for defining anonymous functions like above
- default value
- matching placeholder whose value is ignored
- use for constructing setter method names boolean functions (empty_?)
> Personally I think that Python is great for small simple things, but > as soon as you start to scale the lack of statically checked > guarantees starts to bite you.
What you said about the problems with dynamically typed scripting language is very true. Python is so powerful but the code is so fragile. You need to write a lot of tests. This is exactly why I'm trying to learn Scala.
Thanks for your explanation about operators.
> Regarding () and {} BTW, you can replace a single-argument argument > list with {}, e.g.
> def myFunction(a: String): Unit = println(a)
> myFunction("foobar") > myFunction { "foobar" }
I find the following three lines of code do the same thing. Thanks for your explanation again. I now understand why the first and second line are equivalent. (But why does Scala allow {} here? Isn't () good enough?)
I'm not sure what the {} does in the third line, though.
> The two calls are equivalent. It makes more sense with the latter > format with multiple argument lists or DSL-like things. I could write > up an example if you're interested, but it might be somewhat involved > if you're not familiar with Scala or Lift.
Thanks. Let me finish the tutorials first :-)
> Overall, my suggestion would be to stick with it and ask questions. I > think it's worth it, and the people here are really helpful.
Yes. I plan to bite the bullet and continue with my learning. And indeed, this is a very friendly and helpful list.
> I find the following three lines of code do the same thing. > Thanks for your explanation again. I now understand > why the first and second line are equivalent. (But why > does Scala allow {} here? Isn't () good enough?)
I find it's good when you're doing a block-like thing where it really expects a single value. Most often I use this with functions that do something "scoped", e.g. acquire a resource and release it, or set some kind of semi-global variable temporarily (RequestVar.doWith, ThreadGlobal.doWith, for example).
> I'm not sure what the {} does in the third line, though.
I personally prefer the last form because my editor will happily eat it and I get some consistency when there's arguments before the function argument. Of course, this is an aesthetic thing, I'm sure other people prefer the parenless form.
> I think this is a bit of a running joke in the scala comunity right
> now - your right, underscore really does have a number of meanings; I
> think this will be changed in some future Scala release.
> Your also forgetting:
> import some.package._
> Cheers, Tim
> On 22 Oct 2009, at 12:57, tiro wrote:
>> underscore. At least four different uses:
>> - "it" for defining anonymous functions like above
>> - default value
>> - matching placeholder whose value is ignored
>> - use for constructing setter method names boolean functions (empty_?)
> > I think this is a bit of a running joke in the scala comunity right
> > now - your right, underscore really does have a number of meanings; I
> > think this will be changed in some future Scala release.
> > Your also forgetting:
> > import some.package._
> > Cheers, Tim
> > On 22 Oct 2009, at 12:57, tiro wrote:
> >> underscore. At least four different uses:
> >> - "it" for defining anonymous functions like above
> >> - default value
> >> - matching placeholder whose value is ignored
> >> - use for constructing setter method names boolean functions (empty_?)
> > > I think this is a bit of a running joke in the scala comunity right
> > > now - your right, underscore really does have a number of meanings; I
> > > think this will be changed in some future Scala release.
> > > Your also forgetting:
> > > import some.package._
> > > Cheers, Tim
> > > On 22 Oct 2009, at 12:57, tiro wrote:
> > >> underscore. At least four different uses:
> > >> - "it" for defining anonymous functions like above
> > >> - default value
> > >> - matching placeholder whose value is ignored
> > >> - use for constructing setter method names boolean functions (empty_?)
It's not full code, but it gives you an idea how an immutable data model might be composed and backed with JPA. There are pain points (java collections) and unanswered questions here (how will the JPA provider initialize such a class), but there's what I feel is a language-level issue. In Scala, if you want methods to immutably evolve an objects' state, then you must, as Jonas did, write your own "setters" that yield a new instance with the modification. Sounds like boilerplate to me, that's another topic.
For the record, I'm not yet fully convinced of the gains in using immutability in a domain model. Domain entities represent the state of an application, and in many cases that changes frequently and naturally. Period. How and why those changes occur are often the result of human behavior (twitter, facebook). These behaviors are not functional in the mathematical sense (at least, not that we've discovered), and so I'm not clear on what we stand to gain in a typical domain model.
Naftoli Gugenheim wrote:
> How hard can automatic save be?
> But how would immutable DAOs work? There was a thread, I think on scala-user, a long time ago discussing it, that pretty much concluded it would be very problematic. David weighed in and said after a long time he concluded that databases represent state.
> I kinda wondered why you haven't pushed forward any more with the
> current record implementation... can one assume that is why - because
> it didn't feel right?
> Some of this stuff is going to be fundamental to how we move forward -
> id love to perhaps discuss something that would be better than what we
> have already. Even if its just pie in the sky talk...
> Cheers, Tim
> On 22 Oct 2009, at 17:22, David Pollak wrote:
>> I don't like mutable fields. I don't like manual saving. Dunno...
>> it's hard to articulate... it just feels wrong in my tummy. Also, I
>> want to be clear that I think Marius did a great job of cleaning up
>> some of the problems with Mapper when he did Record... my comments
>> are not a negative to him... there's just something unsatisfying
>> about the whole approach.
>> > > I think this is a bit of a running joke in the scala comunity right
>> > > now - your right, underscore really does have a number of meanings; I
>> > > think this will be changed in some future Scala release.
>> > > Your also forgetting:
>> > > import some.package._
>> > > Cheers, Tim
>> > > On 22 Oct 2009, at 12:57, tiro wrote:
>> > >> underscore. At least four different uses:
>> > >> - "it" for defining anonymous functions like above
>> > >> - default value
>> > >> - matching placeholder whose value is ignored
>> > >> - use for constructing setter method names boolean functions
>> (empty_?)
i believe that one of the best ways to learn a new programming
language is to read software written in it
when reading Scala code, I rarely say "i don't understand how that
works" and when I do, there's usually a good explanation of it
somewhere on the web.
usually I find myself asking "where is that defined?" or "what part of
the language is that?"
Scala is not like, for example, BASIC, where you can look up FOR, IF/
THEN/ELSE. there's lots of individual and compound punctuation marks
that are very difficult to search for online and in PDFs (try
searching for "!").
a lot of scala also relies on syntactic sugar, such as omitted types
(no ": T" after a val/var/def); the dreaded underbar; operator
overloading; and implicit conversions. you can hate on Java's
verbosity (i know i have), but brevity has its own difficulties.
On Oct 22, 11:44 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?.
> funny, I had stumbled on exactly the same line of code when beginning.
> Took me more than a day to understand what's going on. Especially
> because when you copied code from the PDF version of the Liftbook/Lift
> getting started guide, it would mess up spaces, so I would keep
> loooking for a "_::" operator.
> The Scala guys have really pushed it a bit hard on the use of the
> underscore. At least four different uses:
> - "it" for defining anonymous functions like above
> - default value
> - matching placeholder whose value is ignored
> - use for constructing setter method names boolean functions (empty_?)
bob wrote:
> i believe that one of the best ways to learn a new programming
> language is to read software written in it
> when reading Scala code, I rarely say "i don't understand how that
> works" and when I do, there's usually a good explanation of it
> somewhere on the web.
> usually I find myself asking "where is that defined?" or "what part of
> the language is that?"
> Scala is not like, for example, BASIC, where you can look up FOR, IF/
> THEN/ELSE. there's lots of individual and compound punctuation marks
> that are very difficult to search for online and in PDFs (try
> searching for "!").
Indeed, but even cursory survey of scala will reveal that scala has no operators, only methods. This leads the user to search for docs on type of instance on which the punctuated invocation is made. I don't see the confusion there. You could of course make an argument on implicits ...
> a lot of scala also relies on syntactic sugar, such as omitted types
> (no ": T" after a val/var/def); the dreaded underbar; operator
> overloading; and implicit conversions. you can hate on Java's
> verbosity (i know i have), but brevity has its own difficulties.
> On Oct 22, 11:44 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
>> The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?.
>> -------------------------------------
>> tiro<tim.romb...@googlemail.com> wrote:
>>> override def validations = validPriority _ :: super.validations
>> funny, I had stumbled on exactly the same line of code when beginning.
>> Took me more than a day to understand what's going on. Especially
>> because when you copied code from the PDF version of the Liftbook/Lift
>> getting started guide, it would mess up spaces, so I would keep
>> loooking for a "_::" operator.
>> The Scala guys have really pushed it a bit hard on the use of the
>> underscore. At least four different uses:
>> - "it" for defining anonymous functions like above
>> - default value
>> - matching placeholder whose value is ignored
>> - use for constructing setter method names boolean functions (empty_?)
ngocdaothanh wrote:
> Because Lift's ad is so good.
*boom*
For example:
> "Lift is the only new framework in the last four years to offer fresh
> and innovative approaches to web development. It's not just some
> incremental improvements over the status quo, it redefines the state
> of the art. If you are a web developer, you should learn Lift. Even if
> you don't wind up using it everyday, it will change the way you
> approach web applications."
> Lift can't be used without Scala. Is there a plan to implement Lift in
> Clojure, for example? :D
> On Oct 22, 3:47 pm, TylerWeir <tyler.w...@gmail.com> wrote:
>> On Oct 22, 2:02 am, ngocdaothanh <ngocdaoth...@gmail.com> wrote:
>>> jlist9,
>>> This is a Lift group, but I have to say I feel the same about Scala.
>>> I had to ask for advice here:http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
>>> Scala may help me to get my work done for the day. But I don't feel
>>> happy with Scala. Scala makes me feel I'm a slave all the day to
>>> machines (or Scala itself!).
>> If it makes you feel like a slave, why are you using Scala at all
>> then?
>>> On Oct 22, 2:13 pm, jlist9 <jli...@gmail.com> wrote:
>>>> override def validations = validPriority _ :: super.validations
>>>> This is a more of a comment about Scala than one about Lift - this does
>>>> look cryptic to me. And this is just one of the simpler syntax that confuses
>>>> people, who are new to the language. And I'm one of them.
>>>> I understand that you don't have to learn all the tricks/syntax to start
>>>> coding in Scala but you do have to understand it when you read
>>>> source code of libraries written by someone with much more advanced
>>>> language skills.
>>>> In David's book he says "After more than two years of coding Scala, ...
>>>> My brain has finally stopped hurting." This sounds like a very high
>>>> barrier to entry.
>>>> I'm just wondering why Scala has to be so complicated. I'm sure a lot
>>>> of things in Scala have their reasons but at the mean time I also
>>>> suspect that many of the odd things are there to reduce
>>>> typing, which is advertised as one of the advantages of this language -
>>>> conciseness. (I could be very wrong due to my lack of understanding.)
>>>> If the latter is true, I feel that I'd rather type a little more to make the
>>>> code easier to read.
>>>> Just feeling a little frustrated learning Scala. I think it's much
>>>> easier learning
>>>> Java. Not much surprise. Not sure if anyone shares my experience
>>>> (and opinion, if there is one.)
>>>> On Wed, Oct 21, 2009 at 3:56 PM, Randinn <rand...@gmail.com> wrote:
>>>>> http://localhost3000.de/2009/10/a-quick-glance-at-lift/ >>>>> The site above is a blog post from a Rails developer, he had some good
>>>>> and bad things to say about Lift and since I do not know enough to
>>>>> debate with him I thought I'd post it here.
On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis <burningodzi...@gmail.com>wrote:
> My head just exploded. Twice.
That explains the wet face this morning when I woke up... thought it was the
dog licking it... :)
> ngocdaothanh wrote:
> > Because Lift's ad is so good.
> *boom*
It was good. My first thought was "Yeah....
rIIIIIIIIIIIIIIIIIIIIIIIIIIIIIGHT!" Let's see what they mean.....
And voila... here I am.. so it was good, if only because it was right :)
> For example:
> > "Lift is the only new framework in the last four years to offer fresh
> > and innovative approaches to web development. It's not just some
> > incremental improvements over the status quo, it redefines the state
> > of the art. If you are a web developer, you should learn Lift. Even if
> > you don't wind up using it everyday, it will change the way you
> > approach web applications."
> > Lift can't be used without Scala. Is there a plan to implement Lift in
> > Clojure, for example? :D
> > On Oct 22, 3:47 pm, TylerWeir <tyler.w...@gmail.com> wrote:
> >> On Oct 22, 2:02 am, ngocdaothanh <ngocdaoth...@gmail.com> wrote:
> >>> jlist9,
> >>> This is a Lift group, but I have to say I feel the same about Scala.
> >>> I had to ask for advice here:
> http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
> >>> Scala may help me to get my work done for the day. But I don't feel
> >>> happy with Scala. Scala makes me feel I'm a slave all the day to
> >>> machines (or Scala itself!).
> >> If it makes you feel like a slave, why are you using Scala at all
> >> then?
> >>> On Oct 22, 2:13 pm, jlist9 <jli...@gmail.com> wrote:
> >>>> override def validations = validPriority _ :: super.validations
> >>>> This is a more of a comment about Scala than one about Lift - this
> does
> >>>> look cryptic to me. And this is just one of the simpler syntax that
> confuses
> >>>> people, who are new to the language. And I'm one of them.
> >>>> I understand that you don't have to learn all the tricks/syntax to
> start
> >>>> coding in Scala but you do have to understand it when you read
> >>>> source code of libraries written by someone with much more advanced
> >>>> language skills.
> >>>> In David's book he says "After more than two years of coding Scala,
> ...
> >>>> My brain has finally stopped hurting." This sounds like a very high
> >>>> barrier to entry.
> >>>> I'm just wondering why Scala has to be so complicated. I'm sure a lot
> >>>> of things in Scala have their reasons but at the mean time I also
> >>>> suspect that many of the odd things are there to reduce
> >>>> typing, which is advertised as one of the advantages of this language
> -
> >>>> conciseness. (I could be very wrong due to my lack of understanding.)
> >>>> If the latter is true, I feel that I'd rather type a little more to
> make the
> >>>> code easier to read.
> >>>> Just feeling a little frustrated learning Scala. I think it's much
> >>>> easier learning
> >>>> Java. Not much surprise. Not sure if anyone shares my experience
> >>>> (and opinion, if there is one.)
> >>>> On Wed, Oct 21, 2009 at 3:56 PM, Randinn <rand...@gmail.com> wrote:
> >>>>> http://localhost3000.de/2009/10/a-quick-glance-at-lift/ > >>>>> The site above is a blog post from a Rails developer, he had some
> good
> >>>>> and bad things to say about Lift and since I do not know enough to
> >>>>> debate with him I thought I'd post it here.
On Fri, Oct 23, 2009 at 9:29 AM, Jim Barrows <jim.barr...@gmail.com> wrote:
> On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis <burningodzi...@gmail.com>wrote:
>> My head just exploded. Twice.
> That explains the wet face this morning when I woke up... thought it was
> the dog licking it... :)
>> ngocdaothanh wrote:
>> > Because Lift's ad is so good.
>> *boom*
> It was good. My first thought was "Yeah....
> rIIIIIIIIIIIIIIIIIIIIIIIIIIIIIGHT!" Let's see what they mean.....
> And voila... here I am.. so it was good, if only because it was right :)
>> For example:
>> > "Lift is the only new framework in the last four years to offer fresh
>> > and innovative approaches to web development. It's not just some
>> > incremental improvements over the status quo, it redefines the state
>> > of the art. If you are a web developer, you should learn Lift. Even if
>> > you don't wind up using it everyday, it will change the way you
>> > approach web applications."
>> > Lift can't be used without Scala. Is there a plan to implement Lift in
>> > Clojure, for example? :D
I've thought about it and even done some initial poking around with
Clojure. It could be done, but I really like static typing so don't want to
spend a lot of time in Clojure's unityped land.
>> > On Oct 22, 3:47 pm, TylerWeir <tyler.w...@gmail.com> wrote:
>> >> On Oct 22, 2:02 am, ngocdaothanh <ngocdaoth...@gmail.com> wrote:
>> >>> jlist9,
>> >>> This is a Lift group, but I have to say I feel the same about Scala.
>> >>> I had to ask for advice here:
>> http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
>> >>> Scala may help me to get my work done for the day. But I don't feel
>> >>> happy with Scala. Scala makes me feel I'm a slave all the day to
>> >>> machines (or Scala itself!).
>> >> If it makes you feel like a slave, why are you using Scala at all
>> >> then?
>> >>> On Oct 22, 2:13 pm, jlist9 <jli...@gmail.com> wrote:
>> >>>> override def validations = validPriority _ :: super.validations
>> >>>> This is a more of a comment about Scala than one about Lift - this
>> does
>> >>>> look cryptic to me. And this is just one of the simpler syntax that
>> confuses
>> >>>> people, who are new to the language. And I'm one of them.
>> >>>> I understand that you don't have to learn all the tricks/syntax to
>> start
>> >>>> coding in Scala but you do have to understand it when you read
>> >>>> source code of libraries written by someone with much more advanced
>> >>>> language skills.
>> >>>> In David's book he says "After more than two years of coding Scala,
>> ...
>> >>>> My brain has finally stopped hurting." This sounds like a very high
>> >>>> barrier to entry.
>> >>>> I'm just wondering why Scala has to be so complicated. I'm sure a lot
>> >>>> of things in Scala have their reasons but at the mean time I also
>> >>>> suspect that many of the odd things are there to reduce
>> >>>> typing, which is advertised as one of the advantages of this language
>> -
>> >>>> conciseness. (I could be very wrong due to my lack of understanding.)
>> >>>> If the latter is true, I feel that I'd rather type a little more to
>> make the
>> >>>> code easier to read.
>> >>>> Just feeling a little frustrated learning Scala. I think it's much
>> >>>> easier learning
>> >>>> Java. Not much surprise. Not sure if anyone shares my experience
>> >>>> (and opinion, if there is one.)
>> >>>> On Wed, Oct 21, 2009 at 3:56 PM, Randinn <rand...@gmail.com> wrote:
>> >>>>> http://localhost3000.de/2009/10/a-quick-glance-at-lift/ >> >>>>> The site above is a blog post from a Rails developer, he had some
>> good
>> >>>>> and bad things to say about Lift and since I do not know enough to
>> >>>>> debate with him I thought I'd post it here.
It's often hard to describe some (I'd say most) of the Scala syntax
if you want to search for an answer online.
It would be great if the eclipse plugin can tell you what the code is
trying to do and what kind of syntax is that, for example, linking
an operator back to a method name.
On Fri, Oct 23, 2009 at 6:27 AM, bob <rbpas...@gmail.com> wrote:
> i believe that one of the best ways to learn a new programming
> language is to read software written in it
> when reading Scala code, I rarely say "i don't understand how that
> works" and when I do, there's usually a good explanation of it
> somewhere on the web.
> usually I find myself asking "where is that defined?" or "what part of
> the language is that?"
> Scala is not like, for example, BASIC, where you can look up FOR, IF/
> THEN/ELSE. there's lots of individual and compound punctuation marks
> that are very difficult to search for online and in PDFs (try
> searching for "!").
> a lot of scala also relies on syntactic sugar, such as omitted types
> (no ": T" after a val/var/def); the dreaded underbar; operator
> overloading; and implicit conversions. you can hate on Java's
> verbosity (i know i have), but brevity has its own difficulties.
> On Oct 22, 11:44 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
>> The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?.
>> funny, I had stumbled on exactly the same line of code when beginning.
>> Took me more than a day to understand what's going on. Especially
>> because when you copied code from the PDF version of the Liftbook/Lift
>> getting started guide, it would mess up spaces, so I would keep
>> loooking for a "_::" operator.
>> The Scala guys have really pushed it a bit hard on the use of the
>> underscore. At least four different uses:
>> - "it" for defining anonymous functions like above
>> - default value
>> - matching placeholder whose value is ignored
>> - use for constructing setter method names boolean functions (empty_?)
jlist9 wrote:
> It's often hard to describe some (I'd say most) of the Scala syntax
> if you want to search for an answer online.
I can't relate with that. I've been coding scala for 3-4 months, and I've never had any problem finding method definitions. Most of this probably had to do with that fact that I was reading through several language overviews and tutorials.
> It would be great if the eclipse plugin can tell you what the code is
> trying to do and what kind of syntax is that, for example, linking
> an operator back to a method name.
I'll repeat: there are no operators in scala. Not a single one. "linking an operator back to a method name" doesn't make sense. Accept that _everything_ in scala, except methods, is an object, and as such adheres to its respective class contract. If you need to look up the meaning of an "operator," all you need to know is the type on which it is being invoked. The only real complexity in this resolution then is introduced by implicits.
> On Fri, Oct 23, 2009 at 6:27 AM, bob <rbpas...@gmail.com> wrote:
>> i believe that one of the best ways to learn a new programming
>> language is to read software written in it
>> when reading Scala code, I rarely say "i don't understand how that
>> works" and when I do, there's usually a good explanation of it
>> somewhere on the web.
>> usually I find myself asking "where is that defined?" or "what part of
>> the language is that?"
>> Scala is not like, for example, BASIC, where you can look up FOR, IF/
>> THEN/ELSE. there's lots of individual and compound punctuation marks
>> that are very difficult to search for online and in PDFs (try
>> searching for "!").
>> a lot of scala also relies on syntactic sugar, such as omitted types
>> (no ": T" after a val/var/def); the dreaded underbar; operator
>> overloading; and implicit conversions. you can hate on Java's
>> verbosity (i know i have), but brevity has its own difficulties.
>> On Oct 22, 11:44 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
>>> The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?.
>>> -------------------------------------
>>> tiro<tim.romb...@googlemail.com> wrote:
>>>> override def validations = validPriority _ :: super.validations
>>> funny, I had stumbled on exactly the same line of code when beginning.
>>> Took me more than a day to understand what's going on. Especially
>>> because when you copied code from the PDF version of the Liftbook/Lift
>>> getting started guide, it would mess up spaces, so I would keep
>>> loooking for a "_::" operator.
>>> The Scala guys have really pushed it a bit hard on the use of the
>>> underscore. At least four different uses:
>>> - "it" for defining anonymous functions like above
>>> - default value
>>> - matching placeholder whose value is ignored
>>> - use for constructing setter method names boolean functions (empty_?)
you can't easily tell that bar is being imported via foo._ .
what is bar's return type?
what does ~!~ do?
i'm not saying its not possible to track all this down, but you can't
just print out a listing of a class and take it on the subway. you
have to have access to the scaladocs and possibly even the sources.
On Fri, Oct 23, 2009 at 9:47 PM, bob <rbpas...@gmail.com> wrote:
> >I'll repeat: there are no operators in scala
> s/operators/methods-with-operator-like-names/
> anywhere, here's a typical case:
> import some.library.package.foo._
> val a = bar 42
> val b = a ~!~ 3.14159
> you can't easily tell that bar is being imported via foo._ .
> what is bar's return type?
> what does ~!~ do?
> i'm not saying its not possible to track all this down, but you can't
> just print out a listing of a class and take it on the subway. you
> have to have access to the scaladocs and possibly even the sources.
> --b
-- Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall
> On Fri, Oct 23, 2009 at 9:47 PM, bob <rbpas...@gmail.com> wrote:
>> >I'll repeat: there are no operators in scala
>> s/operators/methods-with-operator-like-names/
>> anywhere, here's a typical case:
>> import some.library.package.foo._
>> val a = bar 42
>> val b = a ~!~ 3.14159
>> you can't easily tell that bar is being imported via foo._ .
>> what is bar's return type?
>> what does ~!~ do?
>> i'm not saying its not possible to track all this down, but you can't
>> just print out a listing of a class and take it on the subway. you
>> have to have access to the scaladocs and possibly even the sources.
>> --b
> --
> Viktor Klang
> | "A complex system that works is invariably
> | found to have evolved from a simple system
> | that worked." - John Gall
>> On Fri, Oct 23, 2009 at 9:47 PM, bob <rbpas...@gmail.com> wrote:
>>> >I'll repeat: there are no operators in scala
>>> s/operators/methods-with-operator-like-names/
>>> anywhere, here's a typical case:
>>> import some.library.package.foo._
>>> val a = bar 42
>>> val b = a ~!~ 3.14159
>>> you can't easily tell that bar is being imported via foo._ .
>>> what is bar's return type?
>>> what does ~!~ do?
>>> i'm not saying its not possible to track all this down, but you can't
>>> just print out a listing of a class and take it on the subway. you
>>> have to have access to the scaladocs and possibly even the sources.
>>> --b
>> --
>> Viktor Klang
>> | "A complex system that works is invariably
>> | found to have evolved from a simple system
>> | that worked." - John Gall
On Fri, Oct 23, 2009 at 3:28 PM, Viktor Klang <viktor.kl...@gmail.com>wrote:
> On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows <jim.barr...@gmail.com>wrote:
>> On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang <viktor.kl...@gmail.com>wrote:
>>> But if you name your method: "ashiuahsdyasdasd" what does it do?
>> Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read >> it....
> Chtuluh ftagn! ;D
Huh. Now he's 6 inches tall and has a red nose.... interesting.
Also I think we've made our point about cryptic method names whether there alphanumeric or not, whether you call them operators or not... are problematic.
Now excuse me... cthulu appears to be mucking with my code....
> But if you name your method: "ashiuahsdyasdasd" what does it do?
> On Fri, Oct 23, 2009 at 9:47 PM, bob <rbpas...@gmail.com> wrote:
> > >I'll repeat: there are no operators in scala
> > s/operators/methods-with-operator-like-names/
> > anywhere, here's a typical case:
> > import some.library.package.foo._
> > val a = bar 42
> > val b = a ~!~ 3.14159
> > you can't easily tell that bar is being imported via foo._ .
> > what is bar's return type?
> > what does ~!~ do?
> > i'm not saying its not possible to track all this down, but you can't
> > just print out a listing of a class and take it on the subway. you
> > have to have access to the scaladocs and possibly even the sources.
> > --b
> --
> Viktor Klang
> | "A complex system that works is invariably
> | found to have evolved from a simple system
> | that worked." - John Gall
> > > you can't easily tell that bar is being imported via foo._ .
> > > what is bar's return type?
> > > what does ~!~ do?
> > > i'm not saying its not possible to track all this down, but you can't
> > > just print out a listing of a class and take it on the subway. you
> > > have to have access to the scaladocs and possibly even the sources.
> > > --b
> > --
> > Viktor Klang
> > | "A complex system that works is invariably
> > | found to have evolved from a simple system
> > | that worked." - John Gall
> Scala is not like, for example, BASIC, where you can look up FOR, IF/
> THEN/ELSE. there's lots of individual and compound punctuation marks
> that are very difficult to search for online and in PDFs (try
> searching for "!").
This is where I am coming from, coding after a 16 or so year hiatus
and my main language was basic so I guess I am one of the rare ones
here who doesn't have the OOP/Java hang-ups, I just have a whole
different set of hang-ups to deal with. I have been looking at Scala
for some months and have to admit it is starting to sink in, of course
having to learn everything else in order to learn it is making it take
a bit longer.
