announcement: a lazy visual functional programming language
gma...@little-lisper.org
The Juk (prounounced "jook")
We are making available an early release version of the Juk IDE. The
Juk is a lazy visual functional programming language. Programming is
done by defining and connecting computational units known as "juks"
("roach", in Hebrew slang, following the Russian word for
"beatle").
The Juk is lazy, functional and visual. Juk parameters are identified
by name. Juks provide a natural form of lambda-abstraction. Encoding
self-application (e.g., a fixed-point combinator) amounts to a
self-pointing arc. Mutual recursion and multiple fixed points are just
as easy to write.
The Juk supports the creation and incorporation of libraries, and
comes with:
- A builtin set of juks operating on the primitive types
- A juk library that needs to be incorporated into the Juk IDE before
it can be used. This is done by extending the Juk Library search
path. Any number of additional libraries can be added. Reading over
the library code will provide you with many examples of how to program
with Juks.
In the spirit of Scheme and other functional languages, the Juk is
properly tail recursive.
The Juk language provides for Scheme-like polymorphic vectors with
mutation. This is the basic side effect in the system.
IO is currently rather limited, but great things are in the works, so
please stay tuned!
The Juk is essentially language-independent: Names are Unicode-based,
and can be noted in any language that is available with with your Java
System. Other than names, numbers, and other primitive types, Juk
programming is entirely graphical.
The documentation is very rudimentary. So is the debugger. However,
the Juk is an on-going project, and is constantly being improved. We
value and appreciate your feedback!
To try our the Juk, check out the temporary homepage:
http://www.cs.bgu.ac.il/~shemeas/juks/
Kind regards,
Mayer & Assaf
Hans Oesterholt-Dijkema
--
Hans
Mike Thyer
I'm curious to know if there is an easy way to see how the standard
library juks have been implemented, they seem to provide more
substantial examples than the documentation. I can instantiate them,
but so far have only been able to see their innards with difficulty by
looking through the XML.
I haven't been able to get self-application to work. The GUI seems to
prevent edges crossing from one scope to another, this prevents nested
closures from accessing values in an enclosing closure in the usual
way, and this prevents direct self-application.
I managed to implement factorial by abstracting out the direct
self-application, and repeatedly re-applying:
fact x = f f x
where
f rec x = if x==0 then 1 else x * rec rec (x-1)
But I think the standard library implementation is probably using a
different technique.
What are your plans for the future?
It would be good to see a graphical representation of the evaluation in
progress.
Best regards,
Mike
Raffael Cavallaro
> To try our the Juk, check out the temporary homepage:
>
> http://www.cs.bgu.ac.il/~shemeas/juks/
Looks like Prograph - was that an inspiration for Juk?
Mayer
Mayer
Mayer
definitely possible: Just draw an edge from the lambda out-dock into
some in-dock *by traveling outside the juk*.
All the recursive functions implemented with juks (and there are many)
are implemented using self-application only. It is possible to encode a
fixed-point combinator but this isn't really needed, since
self-application is just an edge from a juk onto itself and is much
simpler. It's also possible to define a recursive call by adding the
juk to the library and the inserting the juk from the library where you
would like to make the call, but this too isn't simpler than
self-application, and just fille the library with juks that otherwise
you might not wish to expose. One of the amazing things about the juk
system is just how easy it is to use self-application.
Kind regards,
Mayer
Mayer
juk will include a very easy mechanism for adding builtins by encoding
them directly in Java... This will be the mechanism for re-using must
of the Java class library. :-) This of course doesn't answer the
objection implied by your comment -- that complex juks can be unwieldy.
You are right. However, we hope that very complex components could be
built ouf of combining pre-packaged building blocks, regardless of
whether these are builtins or written in terms of juks themselves. I
would definitely not write a Scheme compiler using juks though. :-)
Mayer
David Hopwood
> No it wasn't. We'll look into prograph.
<boggle>. So much reinvention, so little awareness of (even recent) history.
See also <http://c2.com/cgi/wiki?GraphicalProgrammingLanguage>.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
David Hopwood
> Mayer wrote:
>
>> No it wasn't. We'll look into prograph.
>
> <boggle>. So much reinvention, so little awareness of (even recent)
> history.
That came out a bit pointed. I should say that I meant it as a criticism
directed at the practice of programming language design in general, not
specifically the design or designers of Juk.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
Ray Dillinger
> David Hopwood wrote:
>
>> Mayer wrote:
>>
>>> No it wasn't. We'll look into prograph.
>>
>>
>> <boggle>. So much reinvention, so little awareness of (even recent)
>> history.
>
>
> That came out a bit pointed. I should say that I meant it as a criticism
> directed at the practice of programming language design in general, not
> specifically the design or designers of Juk.
>
I think this is a very common thing with programming language
design. Most people who create programming languages don't
actually already know more than six or seven programming languages.
If one gets so far and still hasn't found something that suits,
one tends to assume that it doesn't exist, and build it.
That someone else has done so already means very little. The
fact is that it's virtually impossible to *find* a language
that does x and y and z, unless the people you talk to and
interact with already know that language. Prograph is obscure.
Design aesthetics are hard to search on. The odds against
someone who wants a language like Prograph actually finding
Prograph are fairly large.
Bear
Hans Oesterholt-Dijkema
> Your point has occurred to us and is well-taken. Future versions of the
> juk will include a very easy mechanism for adding builtins by encoding
> them directly in Java...
Still I like the fact that programs could be build visually by
assembling and connecting graphical entities. Have you investigated
in a 3D "program universe"?
Best whishes,
Hans Oesterholt
Mayer
I am not sure I would know how to justify Ray's comment that most
people who create a language do not know more than 6-7 languages, but I
think your second paragraph provides a great answer.
We did what we thought was a decent search of the literature. Obviously
it wasn't good enough. I'll need to read up on prograph before I
understand why we didn't find it: Have we been looking under the wrong
keywords, have we been looking in the wrong places, etc.
In any event, this is just the kind of feedback we need!
Thanks,
Mayer
Paul
"Mayer" <gma...@cs.bgu.ac.il> wrote in message
news:1123171819....@o13g2000cwo.googlegroups.com...
I tried the Mac version of Prograph 10 years or so ago (v2.5) They
reinvented themselves after that, trying (unsuccessfully AFAIK) to go cross
platform and raising their price to the point I was no longer interested;
they also changed their name to Pictorius at some point (multiple
bankruptcies occurred). The language was actually pretty good in its day,
but never caught on (as usual) and is long since gone from the market.
alex...@gmail.com
>
> http://www.cs.bgu.ac.il/~shemeas/juks/
>
For some reason, the code representation does not look very compact
to me. It's as though a couple of conditionals take up the whole
page. Is there anything that can be done about it?
Raffael Cavallaro
> For some reason, the code representation does not look very compact
> to me. It's as though a couple of conditionals take up the whole
> page. Is there anything that can be done about it?
The code representation uses signs - pictures that physically resemble
that which they signify - that is, the code representations try to
visually resemble the flow of data in the program.
What if we invented some way to more compactly represent signs so that
this new representation didn't necessarily have any visual resemblance
to the thing it signified. We could call such abstractions "symbols."
Now imagine using these symbols to represent the speech sounds of a
human language. We could call this symbolic representation of human
speech "writing." Writing would be much more compact than using signs,
all the more so for complex concepts.[1]
Then we could take the final step and express programs in writing. ;^)
I brought up Prograph earlier because, though it was fun to use, to
those of us with much experience with it, it quickly became clear that
any reasonably complex algorithm was a hopeless tangle of connections,
even if you allow for the simplification of subroutines to single
signs. I asked because I expected that the developers of juks had
somehow improved on the decade of development that Prograph/Pictorius
put into their language. It turned out that they hadn't even heard of
it. It seems likely that they'll be revisiting all of the pitfalls of
Prograph for a second time, only to discover, as Prograph/Pictorius
users did, that text is actually a better medium for the expression of
complex ideas, just as symbolic writing is a better medium for the
expression of complex ideas than are signs.
[1] Don't be misled by the oft-repeated though false claim that Chinese
characters are purely ideographic signs - they also frequently contain
a phonetic component allowing their representation of all of spoken
Chinese, not just those words/concepts for which a picture-sign exists.
Nimish Shah onetel.com>
> A lazy visual functional programming language:
> The Juk (prounounced "jook")
>
> We are making available an early release version of the Juk IDE. The
> Juk is a lazy visual functional programming language. Programming is
> done by defining and connecting computational units known as "juks"
> ("roach", in Hebrew slang, following the Russian word for
> "beatle").
>
> The Juk is lazy, functional and visual. Juk parameters are identified
> by name. Juks provide a natural form of lambda-abstraction. Encoding
> self-application (e.g., a fixed-point combinator) amounts to a
> self-pointing arc. Mutual recursion and multiple fixed points are just
> as easy to write.
Just been reading "Principles of Functional Programming" and there is a
similarity been the picture of Juk on the website and Data Flow
implementations (pg 104 onwards). Hence the question is Juk just a
Data-flow implementation with a nice GUI onto it?
Nim.
Bradd W. Szonye
David Hopwood wrote:
> <boggle>. So much reinvention, so little awareness of (even recent) history.
I suspect that reinvention is especially common with recent history.
Students and engineers both use fairly old tools -- the latest version,
maybe, but the underlying technology is ten years old or more. When I
started college in 1989, the intro programming course had just switched
from Pascal to C, and the C++ course was brand-new (as evidenced by the
instructors' cluelessness about constructors and destructors, a
fundamental aspect of C++ programming). Now, Java is popular in schools,
and that's also ten years old.
Unless you're deliberately keeping up with recent developments, it's
easy to overlook them. For that matter, it's often worthwhile to ignore
new stuff, given the faddish, marketing-driven elements of the
programming world and the conservative nature of real engineering work.
Heck, I can't count the engineers I've met who've never heard of a splay
tree or pairing heap, and that's old algorithmic tech by now.
It's just as bad, maybe worse, when once-common tools fall out of the
mainstream, because they become unfashionable. So don't be surprised if
you see people reinventing COBOL or FORTRAN features that have since
fallen by the wayside.
--
Bradd W. Szonye
http://www.szonye.com/bradd