Clojure-turtle – Logo programming language in a Clojure context | Hacker News Reader

Clojure-turtle – Logo programming language in a Clojure context

github.com

106 pointstosh66 comments

Using Clojure as the first language is interesting. Being one of the most expressive and efficient (I am not talking about clock cycles here) languages I've used, I think it will set a great mindset for programming.

Clojure is declarative, you tell what you want, not how you want it. It uses immutable data structures and functional programming. It teaches you a sane, safe and beautiful way of working on the problems rather than working against/around/because of your language (e.g building OOP design patterns rather than just solving the problem at hand).

Some people might disagree, but Clojure is a very hands-on and practical language. There's not much syntax or quirks to learn; just a big standard library of very useful functions for processing and transforming data.

>Being one of the most expressive and efficient (I am not talking about clock cycles here) languages I've used

"Productive" seems to be the right word here.

> There's not much syntax or quirks to learn

Except if you don't know Java.

I rarely need to directly interact with Java as a Clojure developer. It of course helps to know the host platform but I don’t think it’s a requirement for getting started with the language.

If it is a dealbreaker you can always stick to ClojureScript, but then you need to know the ins and outs of JavaScript.

Understanding JavaScript is really only necessary if you want to use JavaScript libraries. It still amazes me that the same code can be used on the JVM and in a JavaScript environment most of the time without really needing to understand the details of either platform.

This is a common misconception. I've never written a line of Java in my life, but have been a professional Clojure dev for several years. I never need to interact directly with Java, because most of the libraries you want to use do that for you anyway, and the language itself is self-supporting and comprehensive to not require interop for nearly everything.

I'd like to second this. Clojure (& ClojureScript) have come a long way and have a vast pool of libraries and wrappers by now.

It won't hurt to know something about the underlying environment you work with but you don't have to.

I don't know why you assume that I haven't tried Clojure and found the requisite Java knowledge to be a barrier. How did you get into developing Clojure professionally? Personally, learning on my own through resources like Clojure for the Brave and True, I found it difficult.

I'd love to hear things you disliked or found confusing. Just for the sake of seeing through others eyes.

It's been a while since I tried to get into Clojure/Cljs but when I did I remember errors like the one in this article being cryptic:

https://8thlight.com/blog/connor-mendenhall/2014/09/12/cloju...

> Caused by: java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Keyword

What's an ISeq? I can guess that' it's part of clojure's implementation from java.lang.IllegalArgumentException, but that's what I'm talking about when saying that clojure isn't a great first language because of how you have to both understand a little bit about clojure and a little bit about java, when it comes to errors and namespaces.

Clojure doesn't have the most obvious errors in the world to a newcomer, that is true. A good book on Clojure will quickly remove any confusion about what ISeq means, but a bit of practice makes those low-level understandings not required.

The article you mentioned accurately says this:

> Although Clojure's errors are notoriously unfriendly, they're easy to read with a bit of practice

Once you realize that much of what happens in Clojure is based on data sequences, it becomes clear that an individual keyword is not a sequence, so it was probably used incorrectly somewhere.

That's an interesting article comparing the errors from Ruby with Clojure. They are about the same, the only difference is that Clojure gives you a lot more information in the form of an ugly stack trace. Fortunately, many editors in Clojure automatically hide the stack trace and only show the error.

After you've seen errors a few times in your first week using the language, fixing them becomes second nature. This is one of the tradeoffs using a dynamically typed language: there will be more debugging of runtime problems. In return for that, you spend less time on other things. The fact that there are very successful languages in both the dynamic and static typed camps shows that benefits can be found everywhere.

I wonder what would happen if vanilla clojure came with a commonlisp style debugger on error. CL errors can be intimidating but the interactive debugger makes things almost fun.

Figwheel has time-travel debugging, which is nifty. To be honest, my debugging is quite basic and quick, I've been doing it long enough that when I see an error it's clear what the fix is almost immediately. I suspect this is what happens in most languages regardless of their error handling mechanisms.

I never made any assumptions re: you personally, but it is a misconception that you need to know Java to use Clojure.

I started using Clojure directly by reading some books on it several years ago. I had tinkered with Common Lisp for a couple months before switching to Clojure. I convinced my company at the time to use full-stack Clojure/Script on a new project, so my experience quickly ramped up from there.

I mean, from my (admittedly limited) understanding of Clojure, but my significant experience with Java, this doesn't seem to be the case. Clojure lets you pretend that Java objects are essentially record types, and there's only a couple extra bits of syntax you need to know. Other than that, You can almost completely ignore the existence of Java in Clojure. How else is it possible that it's been ported to JavaScript, CLR, etc.?

Clojure was my first language and I agree. Everything made sense, and I was in for an unpleasant awakening when I started to learn other languages. Mutability in particular makes writing sensible code a lot more difficult. And learning how to properly structure object-oriented programs is still a thing I struggle with, many years later.

Clojure's developer ergonomics have spoiled me: I love the repl! And since its stacktraces were the first type of error reporting I was exposed to, I don't think they are as bad as other people make them out to be. Certainly worth the tradeoff considering all the other benefits you get.

Every time I have to touch OO I sink. Even if I understand method ordering and multiple inheritance a bit. Nothing in OO helps me.

Every time I read function first (let's include lisp, scheme or lambda calc way of doing) I get clarity of mind, and spectacular zen attitude to approach problems.

I don't "love" clojure, but I so wish more people started with it.

I'm experiencing the same thing right now. Even in Dynamic languages that claim to support FP like Python and Ruby i feel like i'm i have to concede building a compossible system because the language itself is so coupled that the trade off of code is too high.

The biggest pain point is both languages couple objects to polymorphism. Now if i want runtime dispatch, i have to create an instance of an object and push data inside of it.

It's worth learning about the roots of OO:

https://www.youtube.com/watch?v=G8X-yvDWClc

The ideas were great, but it all went horribly wrong with C++ and never fully recovered. Modern OOP has few benefits of the original vision, while introducing a lot of pitfalls that need to be constantly avoided.

I know about half of the OO roots, and yes, to be correct I should say mainstream post cpp OO, and not Kay Smalltalk OO.

But in a way Kay OO isn't far from FP. He wanted algebras of objects.. he had some mathematical basis for his language design efforts. As opposed to C++ who used some principles to solve large C code base issues (my 2 cents).

It's one of the most compact mind/machine interfaces I've encountered.

Turtles in #lang typed/racket:

http://docs.racket-lang.org/furtle/index.html?q=turtle#%28de...

Was I the only person who did not understand the draw of Logo as a kid? Having to use it in school made me feel like the world viewed me as a lobotomy victim.

And today, whenever one of these teaching-kids-to-program language/environments comes out, I always wonder, "is a real language really beyond the 8-10 year old's grasp?" More importantly, wouldn't using something real be more interesting to kids? The excitement of computers was, for me, about what you could do with them, and if that meant having to learn some scary looking "computer language" then—By God—I would! And it would be exciting!

The turtle did nothing for me except count the minutes before I could go and do something else. Thankfully we had a public library that had computer books. They weren't the best, but they were about real computer things.

I wish someone had introduced me to Lisp as a child. It's so fundamental. I remember thinking in similar terms, and would have had my mind blown on so many different levels if someone had introduced me to Lisp when I was 8-10, or even younger.

I had the opposite experience. I would read my Math book and read about Logo. But, I never experienced a class that taught me how to use Logo. Eventually I taught myself how to code in Scheme in high school but eschewed going into AP CS which I realize was a mistake.

This project is about introducing Lisp to children (or anyone interested in learning)

Logo is a far more powerful programming language than what it would appear at first sight.

Yeah, we had it on one of the new Apple IIe computers our high school received. Fooling around with the graphics was fun for a while, but when I got to read one of the Logo books and it got to all the other things in the language, it became a very cool experience. I think Logo and 6502 assembler made me look at the top and bottom of programming in an amazing way. I will always be grateful for that.

Logo was the first language I learned in an apple ii. It was instrumental in me discovering I liked programming.

controlling turtle robots

https://dspace.mit.edu/bitstream/handle/1721.1/5836/AIM-248....

or stitching patterns

http://www.turtlestitch.org/

might be more engaging

check out the book "turtle geometry: the computer as a medium for exploring mathematics" by abelson (of sicp fame) and diSessa. it's a wonderful book that shows a how a turtle language and the resulting geometry can be used to explore serious ideas.

Logo on an Apple IIe was my first language. I was in second grade, and I enjoyed it immensely. Partly it was because I quickly moved to making animations with it, rather than static drawings. When I made a working analog clock (there was no pause() that I knew of so I made the turtle spin in place to simulate one, and had to measure the correct number of spins!). Of course, with animations you can do arbitrary things, like build games.

> Was I the only person who did not understand the draw of Logo as a kid? Having to use it in school made me feel like the world viewed me as a lobotomy victim.

> And today, whenever one of these teaching-kids-to-program language/environments comes out, I always wonder, "is a real language really beyond the 8-10 year old's grasp?"

> I wish someone had introduced me to Lisp as a child. It's so fundamental. I remember thinking in similar terms, and would have had my mind blown on so many different levels if someone had introduced me to Lisp when I was 8-10, or even younger.

Logo is a real language, and it is extremely similar to Lisp; a lot of people even just refer to it as a Lisp dialect. There's a lot more to Logo than turtle graphics, the same way there's a lot more to Racket or Python or any other language that has a turtle graphics package.

Basically, you were more or less introduced to Lisp when you were a kid, and having to use it in school made you feel like the world viewed you as a lobotomy victim.

The problem you encountered probably stems less from Logo and more from being taught Logo by teachers who barely knew it themselves, and who didn't care about or understand anything beyond turtle graphics, so that's all they're able to teach to students.

Here's a good introduction to Logo by Brian Harvey with an emphasis on symbolic computation: https://mitpress.mit.edu/books/computer-science-logo-style

Thank you! What you describe regarding my experience might very well be possible. And I will look at Logo again. I am sure you are right regarding its design and foundation.

You quoted my question about teaching-kids-to-program languages, but didn't really address it. Are they necessary? Might they not be detrimental? A kid who's interested in programming: wouldn't they be a lot more excited by, say, HTML and JavaScript—which brings the ability to make websites (!!) —than say, moving a robot, virtual or real.

Then again, it is inherently hugely fun to interact with computers in a REPL-style manner, too. I just never felt inspired by the turtle and only kind of resented it. I wanted to learn about bits and bytes and to understand computers.

In addition to all that has been said, if you really want to understand what Logo is, what it teaches, why, etc - then you need to read about it from the man who invented it:

http://www.papert.org/

Want to know why Lego Mindstorms exists? Well...

https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...

That's the work you need to read - but really, learn about the man, learn about Logo. As others have noted, it's more than just turtle graphics - so much more. Unfortunately, educators still have not grasped his ideas fully, and if you look closely, what is often touted out there for teaching children and others programming - is essentially his ideas, reimplemented poorly.

He has written more on the subject than that one book; and his thoughts and ideas (and Logo itself) aren't really about teaching children programming, but teaching children how to think computationally, algorithmically. He saw how and where things were heading long before many others, and he worked to try to get people prepared. Sadly, all people grasped was turtle graphics, but not the larger picture.

I often wonder where we'd be today had more people truly understood and implemented his (and, to be honest, his "muse" / "mentor" / "inspiration", if you will, in Piaget) methods and thoughts on teaching. Most likely in a much better position as a society...

This is great, very small code. The choice of Clojure would make it a bit difficult for a beginner, but hey, then you know a real language.

> This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

#1 reason for a hacker to not work for Google, you could program "Hello, World" and they wouldn't sign off on it.

The fact that they open-source their code is enough. Imposing the requirement that they must support everything they open-source will mean they will open-source less.

Why should everyone support everything they open-source as an official product? I contest everything you say. This is not the #1 reason. It's not even _a_ reason.

You've misunderstood my comment. I'm saying that Google has a reputation for claiming rights to just about anything you present to them. It's that petty IP policy that has this fun little project under their ownership. For many people, particularly those involved in open source, Google's reluctance to let go of employees' side projects is a strong reason to not work there.

It is part of the fine print in the job contract for developers and is pretty common in most companies. You don't create a side project while being employed there without the company claiming ownership of it. It is part of a safety net for the companies so that they don't take a loss by an employee claiming copyright of code they wrote for the company during work hours.

According to law if there is no such clause the developer may claim ownership of code he wrote even if he was employed. The contract protects the company from that but also applies to any code written by employees generally (not a nice thing but prevalent).

It's very, very common that if you send an email to the relevant people, they'll sign off on whatever so long as it's not relevant to the business. They don't really want to retain control over your random side-projects.

Google, on the other hand, seems to believe that absolutely everything its employees ever do is relevant to its business.

They explicitly don't "retain control" (beyond insisting that it's published in their name). It's Apache 2 licensed.

Indeed, the main dev has forked it into his private Github account: https://github.com/echeran/clojure-turtle

Google has IARC (https://opensource.google.com/docs/iarc/), which is a formal process of sending email to the relevant people, and results in a much better legal position than "Bob said it was ok".

Indeed they do - the issue being that according to a handful of Googlers I know, it's surprisingly difficult to get anything through that process.

That's really strange, since we've approved >96% of requests, and except for when someone is on vacation, it's usually within 3 days now.

Given how many reply to the approval emails that they found it fast and happy, i definitely find this surprising.

In any case, you are welcome to have those employees reach out to me, i'd love to understand their experience what went wrong.

Also, not obvious that this is even a side project. The repo has four contributors. Could well be an internal Clojure training thing or something.

You claim it's petty policy, but it's more like an intersection of employment laws and being a public company, with a sprinkle of unfortunate past events.

> #1 reason for a hacker to not work for Google, you could program "Hello, World" and they wouldn't sign off on it.

This is just not true. If you want to write code that isn't owned by the company, you just ask [1]. It takes about 2 minutes to fill out the form.

For one of my projects, the approval came almost insultingly quickly - as if they were saying "please DO NOT associate Google with that idea".

[1] https://opensource.google.com/docs/iarc/

Anyone knows why the ClojureScript code has the same macros (repeat and all) in seperate files? Why can't everything be in the core.cljc file?

https://github.com/google/clojure-turtle/blob/master/src/clj...

It was in order to get the CLJS REPL to feel more like the regular Clojure REPL: https://github.com/google/clojure-turtle/issues/15

The CLJS-macro story is still a little tricky -- CLJS targets the JS runtime, but you can't easily define macros in a self-hosted CLJS REPL (ex: one that you'd embed in a webpage). Lmk if there is a cleaner way now.

Awesome enhancement. I'll keep that in mind. Thanks for the clarification.

related: 20 things to do with a computer (1971) from MIT AI Lab

https://dspace.mit.edu/bitstream/handle/1721.1/5836/AIM-248....

It is exciting that people inside Google is using Clojure. The more Clojure gets popular, the better for the programming community as a whole, even if its usage means indirectly giving more fuel to Oracle.

<smug-mode> On the other hand it also means we will thus be able to one-up Google by using Common Lisp... </smug-mode>

Google already uses Common Lisp for flight search (acquired from ITA Software). They even have a fairly good style guide written by one of the maintainers of ASDF (amongst others):

https://google.github.io/styleguide/lispguide.xml

Logo was my first programming language. #Nostalgic Thanks Google and thanks for Clojure implementation.

BASIC was my first programming language. Starting with the days of the Commodore 64, Apple IIe, and MS GWBASIC, but I never understood it well enough beyond a number guessing game or so. Then I had a class on Logo, and I was doing cool stuff on my own, and it was so fun! Yeah, I love Logo.

During the time of that Logo class, I tried writing a BASIC program for a programming competition with my new-found confidence. But it was such a spectacular fail that my 11-year old self was literally crying.

I find both Logo and Clojure are profound, simple, and powerful in their own ways. A friend and I are working to take the next step with this project and make this a little more accessible/usable. ;)

My first language was BASIC on a Z80 Chip Sol 20 Computer. To play a game you had to type in pages of source code. Man what a pain with the line numbers and debugging for a 7 year old was insane. I then learned some LOGO, Pascal and Forth and then to Assembly in the C64 days for nefarious purposes.

I have to say that when I learned Scratch it reminded me of my old Logo days.

BASIC was my first language too, but LOGO was the first language I attempted to make an interpretor for (also, incidentally, LOGO was the first language I took a class for, just for fun - something Radio Shack offered for the Color Computer, which was the machine I owned).

related (via /r/Clojure): https://docs.racket-lang.org/turtles/Value_Turtles.html

But, but... Clojure is dying language. Someone been crying about that all over the internet just a few weeks ago. Why Google using a dying language?

I've been sarcastic of course. I'm one of those lucky bastards who's got luxury of writing Clojure(script) all day long and get paid for it.

my first programming language was logo. nice job dude!

Yet another example of how interfaces and ADTs (together with layered DSLs) are the central concerts in classic CS.

Honest question: what is nonclassic CS?

systemd

More seriously, everything which made MIT to switch from Scheme to Python in the fundamental CS courses.

is is significant because it shows google is testing clojure, or is it something else?

obviously they're beginning a migration to logo.

If you try the interactive examples on the main Readme page all the way to the end, you'll see there's a gradual, subtle shift from cutesy Logo to Clojure-style functional programming. But I owe more doc-writing along those lines, and they that would make that fuller & clearer.

Reply on news.ycombinator.com