Fresh Clojure Tutorial

[Curran Kelleher]

Hello,

I've created an introductory tutorial for Clojure and Emacs here:
http://lifeofaprogrammergeek.blogspot.com/2009/03/learning-clojure-and-emacs.html

I just wanted to let the community know, maybe it should be linked to
in the wiki?

Best,
Curran

[Krešimir Šojat]

Is link broken? blogpost return pagen not found message.

--
Krešimir Šojat

[Andrew Wagner]

Excellent tutorial. I pretty much zipped right through it, even though I'm on osx and had to figure out the right way to get a git client for myself. Thanks!

[Andrew Wagner]

Oh, I should point out that it looks like your abs examples, under "Learning basic clojure" got mangled.

On Sun, Mar 29, 2009 at 3:34 PM, Curran Kelleher <curran....@gmail.com> wrote:

[Dan Beauchesne]

Looks great, thanks a bunch.

I'm not coming from a Java background so any swing example I can get my
hands on is great.

[Curran Kelleher]

Glad to hear it is a usable tutorial!

It seems like lots of people coming to Clojure not coming from Java
are having difficulties with GUI coding. I think a big list of GUI
examples in Clojure would be the perfect remedy.

@Krešimir - I think blogger was down for a bit that day, the link
should be fine now
@Andrew - thanks for pointing out the mangled code, I fixed it

[e]

i may be in the minority in thinking that eventually (not as a priority, I understand) more and more of the useful stuff from Java should be wrapped ... even if it masks the documentation.  File IO was the last example that I suggested putting in the core.  This GUI question comes up so often, too, but it's a tougher call because it's hard to do without tying clojure to the jvm.  That said, If I NEVER have to use java calls directly, imagine how easy the port if/when clojure ever lives on top of some other vm.

[e]

the port of user code, that is ... much harder for the port of clojure.

[Laurent PETIT]

Yeah,

if there existed some set of functions/macros that could be used to specified user interface stuff at a "high level", while still allowing controlled way of adding GUI specifics at some points, the dream could become true.

I'd love to work on that, if time permitted.
But maybe such thing already exist in the Scheme/CommonLisp world, and could be used or be a source of inspiration ?

2009/4/1 e <evie...@gmail.com>

[Raoul Duke]

(i know this note of mine probably really doesn't help, but)

> But maybe such thing already exist in the Scheme/CommonLisp world, and could
> be used or be a source of inspiration ?

i'm not totally sure what you have in mind, but the subject of "new
researchy approach to doing GUIs that is supposed to be better than
everything else before" is a depressingly common subject matter, i
think, given the actual approaches that ends up really being used most
often.

there's stuff like Adobe's http://lambda-the-ultimate.org/node/563.

there's stuff like FRP in Haskell or PLT-Scheme.

there's stuff like JavaFX (or whatever it is called this week).

there's stuff like X-Windows but driven sanely by Erlang rather than C.

then there's all the stuff that never got used anywhere outside of academia.

etc.

sincerely.

[Laurent PETIT]

Yes, you're certainly right, but I'm only 35 old, and I don't want to yet let my dreams behind me, given that I will certainly (I hope so!) play at least 35 more years in this industry :-)

I was thinking about an approach that would leverage the kind of separation one can find in the industry such as GUI stuff in one file, backend stuff in another, but maybe reconciled thanks to judicious use of higher order functions and conscienscious application of macros.

Something that can be thought of as "workable specs" for the GUI, where one does not have to switch language from one abstraction level to the other.

--
Laurent

2009/4/1 Raoul Duke <rao...@gmail.com>

[Raoul Duke]

> Yes, you're certainly right, but I'm only 35 old, and I don't want to yet
> let my dreams behind me, given that I will certainly (I hope so!) play at
> least 35 more years in this industry :-)

i'd say both:

a) that is good to hear, and i support such attitude! please go forth
and invent, because you might well do something insightful and helpful
to all. (let alone just have fun in the process.)

b) but! please don't forget to try to learn from what other people
have done, especially mistakes made, or long-term problems that arise.
which probably means: find somebody who really knows the breadth of
gui research. you'd hope there'd already be such a person on a list
like this?

:-)

sincerely.

[Antony Blakey]

On 01/04/2009, at 10:47 AM, Laurent PETIT wrote:

> Something that can be thought of as "workable specs" for the GUI,
> where one does not have to switch language from one abstraction
> level to the other.

You should have a look at the Scala wrapping of SWT.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

A Buddhist walks up to a hot-dog stand and says, "Make me one with
everything". He then pays the vendor and asks for change. The vendor
says, "Change comes from within".

[e]

On Tue, Mar 31, 2009 at 8:17 PM, Laurent PETIT <lauren...@gmail.com> wrote:

Yes, you're certainly right, but I'm only 35 old, and I don't want to yet let my dreams behind me, given that I will certainly (I hope so!) play at least 35 more years in this industry :-)

I was thinking about an approach that would leverage the kind of separation one can find in the industry such as GUI stuff in one file, backend stuff in another, but maybe reconciled thanks to judicious use of higher order functions and conscienscious application of macros.

Something that can be thought of as "workable specs" for the GUI, where one does not have to switch language from one abstraction level to the other.

I guess we are being warned about some kind of hunt for perpetual motion or "cold fusion" (maybe I can't use that analogy now - http://www.newscientist.com/article/dn16820) ...

but this doesn't seem that far fetched.  Instead of looking up the docs while you make an application.  write the GUI code how you would want it to work .... and then fix the errors until it is legal code with the desired result.  Then person b tries to use it, and proposes some tweaks that work for the new app and the original app (or shows how to tweak the original app).  etc. (in theory)