Earlier quoted context omitted.
If you understand what the title means well enough to object to its usage, that's solid proof that the title has communicated effectively. > What is a very bad in that title is that it focuses on Racket, just as if the title was: "Racket - this is how Lisp looks like beyond Clojure". That's your own interpretation--you could easily have interpreted it as "Racket--an example of a Lisp beyond Clojure".
I can understand and consider the choice of words to be bad.
Racket – Lisp beyond Clojure
171–179 of 179 posts
Re: Racket – Lisp beyond Clojure
#172Earlier quoted context omitted.
> What were those 'ideals'? What was that vision? I don't know that. > That was McCarthy's vision: a tool for AI research. You don't know that. > No, Scheme went away from the idealized Lisp. -> R6RS. Neat! I'm glad we cleared that up. EDIT: Okay, maybe "You don't know that" is a bit strongly-worded; there's no doubt that that was part of McCarthy's vision, but there's a great more to Lisp than that, and notably, Sch…
> You don't know that. Sure we know what McCarthy developed Lisp for: as a tool for AI research. It's already mentioned in the very first paragraph of the 1960 paper on Lisp. Sure there are several Lisp dialects and a bunch of derived languages, like Scheme. > Or put more tersely, I don't car. Yes, sure. car and cdr.
> Sure there are several Lisp dialects and a bunch of derived languages, like Scheme.
Sure, that's one thing that it was when McCarthy started developing it, but the original Lisp paper doesn't say "only" and you don't know how McCarthy's intentions developed as the language developed.
> > Or put more tersely, I don't car.
> Yes, sure. car and cdr.
Hah! That was an entirely unintentional pun.
Re: Racket – Lisp beyond Clojure
#173Earlier quoted context omitted.
I have been trying to get into the whole Lisp paradigm for 1-2 years now. I own Realm of Racket, amongst a collection of Lisp books. Racket is all the promise of developer-centric power tooling that puts Common Lisp to shame. I recommend you watch one of the core devs, Matt Flath, build a a hygenic macro expander. https://www.youtube.com/watch?v=Or_yKiI3Ha4 Notice how his talk, likely written in its own documentation…
Racket 6.6 doesn't even start on my Mac... crashes immediately.
Re: Racket – Lisp beyond Clojure
#174Earlier quoted context omitted.
> You don't know that. Sure we know what McCarthy developed Lisp for: as a tool for AI research. It's already mentioned in the very first paragraph of the 1960 paper on Lisp. Sure there are several Lisp dialects and a bunch of derived languages, like Scheme. > Or put more tersely, I don't car. Yes, sure. car and cdr.
> Sure we know what McCarthy developed Lisp for: as a tool for AI research. It's already mentioned in the very first paragraph of the 1960 paper on Lisp. > Sure there are several Lisp dialects and a bunch of derived languages, like Scheme. Sure, that's one thing that it was when McCarthy started developing it, but the original Lisp paper doesn't say "only" and you don't know how McCarthy's intentions developed as the…
McCarthy later did not care too much about Lisp development and direction himself, since he was working on core AI topics then. But the field of AI caused massive investment into Lisp during the 70s and 80s, until it died out in the early 90s. We are talking about something like 2 billion USD.
Re: Racket – Lisp beyond Clojure
#175Earlier quoted context omitted.
While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. I have generally found that this is the same problem as with user-defined functions, and it has the same solution: programmers need to doc…
If you need documentation probably you are not writing good code. Documentation is absolutely needed when writing third party libraries, but everyone of your team should know all the aspects of the codebase, at least at high level. If someone doesn't know it then documentation is not the solution. Doing some pair-programming, adding them as reviewers of more pull requests, writing some wiki page that explains the arc…
You get a new member of the team, how do pull-request reviews and pair-programming help them get familiar with old code? Documentation is a way of stating explicitly what might be learned implicitly from those tasks.
> Every time that I've seen some attempt at writing documentation in javadoc or whatever is called in .net, there were always missing parameters in the methods, wrong arguments and method names, parameters not existing anymore and so on
So fix that. review the comments as part of code review - if the documentation is in the code this should be easy. From my memory of Java, doesn't eclipse have some sort of doc sting checker? I'm sure I recall the in-comment parameter names changing when you updated the method name...
Re: Racket – Lisp beyond Clojure
#176Earlier quoted context omitted.
> Sure we know what McCarthy developed Lisp for: as a tool for AI research. It's already mentioned in the very first paragraph of the 1960 paper on Lisp. > Sure there are several Lisp dialects and a bunch of derived languages, like Scheme. Sure, that's one thing that it was when McCarthy started developing it, but the original Lisp paper doesn't say "only" and you don't know how McCarthy's intentions developed as the…
> Sure, that's one thing that it was when McCarthy started developing it, but the original Lisp paper doesn't say "only" and you don't know how McCarthy's intentions developed as the language developed. McCarthy later did not care too much about Lisp development and direction himself, since he was working on core AI topics then. But the field of AI caused massive investment into Lisp during the 70s and 80s, until it…
AI industry has invested into a lot of languages, including Scheme, but also including stuff like C++/Java/Python/Ocaml. Trivially Google has invested more in Python AI than $2 billion, and I wouldn't be surprised if Jane Street has invested more than that in OCaml AI. So I'm not really sure what you're trying to prove here.
Re: Racket – Lisp beyond Clojure
#177Earlier quoted context omitted.
> Sure, that's one thing that it was when McCarthy started developing it, but the original Lisp paper doesn't say "only" and you don't know how McCarthy's intentions developed as the language developed. McCarthy later did not care too much about Lisp development and direction himself, since he was working on core AI topics then. But the field of AI caused massive investment into Lisp during the 70s and 80s, until it…
Ugh, when you say "Lisp" you're talking about "Common Lisp"? AI industry has invested into a lot of languages, including Scheme, but also including stuff like C++/Java/Python/Ocaml. Trivially Google has invested more in Python AI than $2 billion, and I wouldn't be surprised if Jane Street has invested more than that in OCaml AI. So I'm not really sure what you're trying to prove here.
When I say Lisp, I mean Lisp dialects: Maclisp, Interlisp, Standard Lisp, Franz Lisp, EULisp, Euslisp, LeLisp, ISLisp, Common Lisp, ...
But not Scheme, Racket, Logo, Dylan, Javascript, Clojure, Ruby, Python, Mathematica, Perl, TCL, ...
Re: Racket – Lisp beyond Clojure
#178I've recently started porting some bash scripts over to Racket, using https://docs.racket-lang.org/shell-pipeline and it's been pretty straightforward and painless so far!
Link to your code? I would be very interested to see this thus far. I have looked at avesh (CL) and xonsh (Python) because I think the future of fun *nix tooling is like libraries that implement a bash layer to like gradually move code away from shell languages. This is the sweet spot I would want in my life.
Note that the static HTML views are truncated to 10 commits, to save space (useful on larger repos), but the repo itself contains the full history.
Re: Racket – Lisp beyond Clojure
#179Earlier quoted context omitted.
Link to your code? I would be very interested to see this thus far. I have looked at avesh (CL) and xonsh (Python) because I think the future of fun *nix tooling is like libraries that implement a bash layer to like gradually move code away from shell languages. This is the sweet spot I would want in my life.
Not the cleanest, but it's at http://chriswarbo.net/projects/repos/theory-exploration-benc... Note that the static HTML views are truncated to 10 commits, to save space (useful on larger repos), but the repo itself contains the full history.