What Differentiates Gosu From Other Languages?

[Simon Ochsenreither]

Interesting read, also references Scala: http://guidewiredevelopment.wordpress.com/2012/02/27/what-differentiates-gosu-from-other-languages/

[Mark Hammons]

I don't understand most programmers' aversion to functional languages.  Yeah,  it's tough to do at first, but so is every othdr paradigm. This article is pretty terrible if you ask me.

[Robert Kirkpatrick]

Quite terrible about Scala indeed.
Nevertheless interesting about an "IDE-oriented" language, showing where the Scala competition lies.

Robert.

Le 23/05/2012 12:22, Mark Hammons a �crit :

>
> I don't understand most programmers' aversion to functional languages. Yeah, it's tough to
> do at first, but so is every othdr paradigm. This article is pretty terrible if you ask me.
>
> On 2012 5 23 12:02, "Simon Ochsenreither" <simon.och...@googlemail.com

> <mailto:simon.och...@googlemail.com>> wrote:
>
> Interesting read, also references Scala:
> http://guidewiredevelopment.wordpress.com/2012/02/27/what-differentiates-gosu-from-other-languages/
>

--

[Simon Ochsenreither]

This is pretty scary: http://guidewiredevelopment.wordpress.com/2012/05/09/gosus-inconceivable-non-classloader-take-1/

[Robert Kirkpatrick]

Yes indeed - just as an example:
"we flirt with deadlock every time our special loader does its job"

At least the author plays transparency!

Le 23/05/2012 13:10, Simon Ochsenreither a écrit :
> This is pretty scary:
> http://guidewiredevelopment.wordpress.com/2012/05/09/gosus-inconceivable-non-classloader-take-1/

--

[Mark Hammons]

Yeah, this language seems like a winner. I really wish scala developers dealt with non-complicated things like classloader deadlocks instead of the dreaded foldLeft and map functions.

--
Mark Edgar Hammons II - OU Student | Intern at REQU

Cell - 1 (405) 928 8206
Email - markeh...@gmail.com

[Tony Morris]

Well, Scala is pretty complex after all. You should see the flatMap
function! Well, where do I start? Sheesh, I am so overwhelmed right now.
How complex indeed.

On 23/05/12 21:49, Mark Hammons wrote:
> Yeah, this language seems like a winner. I really wish scala developers
> dealt with non-complicated things like classloader deadlocks instead of the
> dreaded foldLeft and map functions.
>
> On Wed, May 23, 2012 at 1:36 PM, Robert Kirkpatrick <rob...@eridan.net>wrote:
>
>> Yes indeed - just as an example:
>> "we flirt with deadlock every time our special loader does its job"
>>
>> At least the author plays transparency!
>>

>> Le 23/05/2012 13:10, Simon Ochsenreither a �crit :
>>
>> This is pretty scary: http://guidewiredevelopment.**
>>> wordpress.com/2012/05/09/**gosus-inconceivable-non-**classloader-take-1/<http://guidewiredevelopment.wordpress.com/2012/05/09/gosus-inconceivable-non-classloader-take-1/>
>>>
>> --
>>
>
>


--
Tony Morris
http://tmorris.net/

[Erik Post]

On Wednesday, 23 May 2012 12:02:29 UTC+2, Simon Ochsenreither wrote:

Interesting read, also references Scala: http://guidewiredevelopment.wordpress.com/2012/02/27/what-differentiates-gosu-from-other-languages/

This article seems a bit more to the point:

http://guidewiredevelopment.wordpress.com/2010/11/18/gosus-secret-sauce-the-open-type-system/

 Their 'open type system' sounds like type providers to me, as I understand them from http://scalamacros.org/usecases/type-providers.html. Sounds pretty cool. Seeing 'driver.DriversLicenses = new ArrayList<DriversLicense>()' was less of a herald of awesomeness.

Cheers,

Erik

[Simon Ochsenreither]

 Their 'open type system' sounds like type providers to me, as I understand them from http://scalamacros.org/usecases/type-providers.html. Sounds pretty cool.

Yes, I'm not sure, but it might even predate the F# stuff.

Interesting that they have given up on the Eclipse IDE support, though.

Independently of the language, Gosu/F#/Scala, I think it really boils down to having not just a few, but a lot of type providers.

Looking at the myriad of query/sql/collection APIs out there in the Scala ecosystem I really hope that SLICK and type providers are a good value proposition for them, so that stuff gets more consistent.

I guess Scala will have few more problems due to not only wanting to have a more general system (macros instead of special compiler interfaces), but also wanting to support the traditional collection API names and integrating it into for comprehensions will be hard.

F# has an interesting approach ... they basically split their collection operations between the part that generates SQL and the part which operates on the resulting collection.

 

[Dave]

http://stackoverflow.com/questions/4975428/whats-the-essential-similarities-and-differences-between-scala-and-gosu-relate

On 23 mei, 19:38, Simon Ochsenreither

<simon.ochsenreit...@googlemail.com> wrote:
> >  Their 'open type system' sounds like type providers to me, as I

> > understand them fromhttp://scalamacros.org/usecases/type-providers.html.

[Bill Burdick]

After looking at the (removed) language comparison chart ( http://web.archive.org/web/20110726124437/http://gosu-lang.org/comparison.shtml ), it seems, to me, like Gosu is similar to Xtend: http://www.eclipse.org/xtend/  The only problem I have with the current Xtend version is that closures aren't compatible with SAMs, so you can't use them with FJ's Function objects, for instance.  I made a patch to help with that and some of the Xtend maintainers helped with some other issues involving closures (with casts and such), so that they work "like they should" in MY Xtend codebase, but it looks like the three changes I use won't actually be integrated until RC1 (and the integration keeps getting bumped farther down the line).

Bill

[Dave]

On 23 mei, 20:51, Bill Burdick <bill.burd...@gmail.com> wrote:
> After looking at the (removed) language comparison chart (http://web.archive.org/web/20110726124437/http://gosu-lang.org/compar...),

It's still there, only renamed
http://gosu-lang.org/compare.html