Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

Common Lisp or Scheme?

Name: Anonymous 2011-08-09 23:13

I'm going to get some basics on functional programming. But there are too fucking many LISP dialects. I know all in all it's all the same shit, but between the two, which one should I use for these little studies?

(And yes, SICP is part of them)

Name: Anonymous 2011-08-09 23:24

Try both.  You can even go through SICP completing each exercise in both languages.

Name: Anonymous 2011-08-09 23:25

Friends don't let friends use Lisp or Scheme.

Name: Anonymous 2011-08-09 23:26

scheme! fuck CL and its broken semantics

Name: Anonymous 2011-08-09 23:48

You need to ask yourself whether you should be programming in a LISP-1 or LISP-2 dialect. Only one is the proper choice. The answer is left as an exercise to the reader

Name: Anonymous 2011-08-09 23:51

Lisp-1, but Scheme is broken. I guess you're screwed!

Name: Anonymous 2011-08-10 0:32

neither scheme nor CL are really all that functional.

Name: Anonymous 2011-08-10 0:36

I use CL for most of my work, but Scheme is nice for certain small projects.

Name: Anonymous 2011-08-10 1:25

>>7
can't tell if unintentional bad pun

Name: Anonymous 2011-08-10 1:27

>>7
All languages are shit. The lisps just happen to be the cream of the shit.

Name: Anonymous 2011-08-10 5:13

Neither of Common Lisp or Scheme have memory pointers, meaning you can't have pointer to a memory cell, beside it's name. It's a major design flaw for a general-purpose programming language.

Name: Anonymous 2011-08-10 5:18

C/C++:

int I;
f(&I);


Lisp:

(let (I)
  (f (cons (lambda () I) (lambda (V) (setf I V)))))



Lisp version is just inefficient and ugly.

Name: Anonymous 2011-08-10 6:03

>>9
OMG OPTIMIZED!

>>1
Learn Scheme first, which is simpler. Use Chicken/Racket/whatever.
Read your SICP, then give CL a try.

Name: Anonymous 2011-08-10 6:03

>>11
Actually CL does have pointers (in most implementations), just they're not portable and using pointers in high-level languages means you have to babysit the GC.
However, I almost never had any need to use pointers in CL after I learned it:
- Use generalized places with SETF
- Use structures, objects, lists, closures, ... (passed by reference; most things are, except atoms such as numbers)
- You really, really want pointer-like functionality? Generalized places can be easily encapsulated into an object and you can change or modify it (just like reference/dereference in C). This is known as `locatives' from LispMachineLisp. Portable implementation for CL: http://permalink.gmane.org/gmane.lisp.sources.code/17 If you want very fast, unportable ones (if you use them often), here's an SBCL extension: http://discontinuity.info/~pkhuong/mcas/sb-locatives.lisp . Original LispM docs about them: http://www.unlambda.com/lmman/lmman_18.html
- In C, you commonly use pointer arguments to return multiple results or modify structures: you don't need to do this in CL, you can just return multiple values, or modify the structure directly (of course, it's bad coding practice to do this without specifying that the function does this).

Even if you can fully emulate pointers using locatives, I rarely used this feature, as it's nicer to just write CL like it was meant to be written.

>>12
It's only inefficient and ugly because you don't know how to write it better. I almost never had to write anything like that myself (although I did write something similar when I was learning the language). If you really can't live without pointers, use locatives, although you'll probably be better off learning to write in a better style.

Name: Anonymous 2011-08-10 6:07

s/object/class instance//

Name: Anonymous 2011-08-10 6:30

>>14
using pointers in high-level languages means you have to babysit the GC.
Not if they are aligned. Also, there is a thing called http://en.wikipedia.org/wiki/Boehm_garbage_collector

Name: Anonymous 2011-08-10 6:32

>>14
It's only inefficient and ugly because you don't know how to write it better.
I need a pointer into the middle of array. There is no way to do it in CL, except passing array+index everywhere.

Name: Anonymous 2011-08-10 6:37

>>14
it's nicer to just write CL like it was meant to be written.
That is what wrong with Lisps. They try to hide low level details, instead of embracing them and build directly on top of assembly language, surpasing C/C++ in being close to metal.

Name: Anonymous 2011-08-10 6:58

>>18
You can do it, but it's not common for most applications.
>>17
Fine, use a locative then (or something similar).

Name: Anonymous 2011-08-10 9:22

>>9
>>10
I meant that they aren't functional in nature. Both involve a lot of side-effects going on.

Name: Anonymous 2011-08-10 9:26

>>18
That is what wrong with Lisps. They try to hide low level details, instead of embracing them and build directly on top of assembly language

That's exactly what's RIGHT about Lisps. Also, you realize that there used to be Lisp Machines right?

This worship of hardware is really harmful. "Worship" really is the right word too: hardware can do no wrong, we must all adjust our behavior and designs to hardware.

I'd rather worship the customer.

Also CL totally has pointers. cons cells are structs with two pointers in them. Fucking C-tards.

Name: Anonymous 2011-08-10 9:32

>>1
I know all in all it's all the same shit

hahaha no. The only thing different languages in the Lisp family share is syntax. If you think syntax is everything, you have a lot to learn.

Name: Anonymous 2011-08-10 9:56

>>21
Why SBCL's runtime is written in C/C++? Because C/C++ is fucking better! Admit it.

Name: Anonymous 2011-08-10 10:01

>>22
If you think syntax is everything, you have a lot to learn.
In case of Lisp, syntax is everything, else macros wont be possible. Lisp also has pretty othogonal semantics, but here are more othogonal languages: for example, Smalltalk and Forth have less core constructs than Lisp.

Name: Anonymous 2011-08-10 10:05

>>24
It should be noted, that extreme othogonality damages usability: remove keywords from Common Lisp and it will become much less usefull.

Name: Anonymous 2011-08-10 10:12

>>24
I think you missed the point.

What I was saying was that syntax is basically the only thing Scheme and CL have in common, and otherwise it's hard to find two more different languages.

Name: Anonymous 2011-08-10 10:13

>>23
The purpose of C is to write a better language in it.
The purpose of C++ is to waste people's time.

Name: Anonymous 2011-08-10 10:22

>>26
Both have dynamic typing, lexical scope, numerical tower arithmetics and high-order functions. The most significant difference is DEFMACRO vs SYNTAX-CASE holywar.

Name: Anonymous 2011-08-10 10:23

>>27
Better language should scale better, without falling-back to C/C++ for low-level stuff.

Name: Anonymous 2011-08-10 10:33

>>28
and symbols being a data structure in CL containing a function, a value, and a property list, whereas symbols in Scheme are just interned strings.

and CL having a ubiquitous object system and Scheme having no object system. CL is CLOS.

and the completely different evaluation rules. ((foo)) is an error in CL but not in Scheme

and CL having both dynamic and lexical scope and Scheme just having lexical scope.

and code in CL at some point being represented as lists and not with Scheme (making many CLers to say that Scheme isn't really Lisp. Honestly Scheme could have syntax and the macros would be just about as easy to deal with.)

and the cultural differences, which are just enormous.

and the general emphasis in CL of using side effects and imperative techniques whereas Scheme is much more functional

and how in CL the main thing you do is make top-level definitions, whereas in Scheme you mostly scope things and have a lot of ((list in the car position) stuff to pass to the result) whereas in CL the car is always a symbol or a lambda literal.

and Scheme having built-in first class continuations.

and the general attitude of anaphoric macros vs hygienic macros

Name: Anonymous 2011-08-10 10:34

>>29
Lisp is "low level stuff" on Lisp Machines. C would be useless on a Lisp Machine.

hardware is fucking arbitrary. Deal with it.

Name: Anonymous 2011-08-10 10:48

>>30
and symbols being a data structure in CL containing a function, a value, and a property list, whereas symbols in Scheme are just interned strings.
and the completely different evaluation rules. ((foo)) is an error in CL but not in Scheme
and CL having both dynamic and lexical scope and Scheme just having lexical scope.

nuances

and CL having a ubiquitous object system and Scheme having no object system. CL is CLOS.
CLOS is an external library. You can implement it for Scheme.

code in CL at some point being represented as lists and not with Scheme (making many CLers to say that Scheme isn't really Lisp. Honestly Scheme could have syntax and the macros would be just about as easy to deal with.)
This.

Name: Anonymous 2011-08-10 10:50

>>31
Hardware is turing-complete. Lisp has macros -> it can scale up from assembly.

Name: Anonymous 2011-08-10 10:55

>>33
eh...
the thing is, it's almost always the case that you don't care about registers or memory management. Might as well abstract it. Who cares? I'll write some assembly if I really do.

Name: Anonymous 2011-08-10 11:01

>>32
CLOS can be implemented as a library, but it really integrates deep into the language core if done right. Scheme doesn't let you rewrite built-ins as generic functions.

Name: Anonymous 2011-08-10 11:04

>>30
also CL's package system is highly integrated with the way symbols and keywords work. None of that is in Scheme, really.

Name: Anonymous 2011-08-10 12:39

>>32
CLOS is part of CL and usually integrated rather deeply, despite the fact that you could implement it in a Lisp that doesn't support it natively. Scheme has Tiny-CLOS as a library.

Name: Anonymous 2011-08-10 16:33

joh joh joh /prog/ is so fresh against /prog/ reddit looks like a rat

Name: Anonymous 2011-08-10 17:20

the answer is clearly racket

Name: Anonymous 2011-08-10 19:30

>>39
Scheme is broken.

Name: Anonymous 2011-08-10 19:33

>>40
define "broken"

Name: Anonymous 2011-08-10 19:38

>>41
begin-for-syntax syntax-e syntax->datum syntax->list syntax-property #' (void) quote-syntax datum->syntax syntax-parameter-value syntax-rule raise-syntax-error internal-definition-context? syntax-parameterize make-set!-transformer prop:set!-transformer free-identifier=? syntax-local-value/immediate syntax-local-transforming-module-provides? syntax-local-module-defined-identifiers syntax-local-module-required-identifiers make-require-transformer (require (lib "stxparam.ss" "mzlib")) syntax? (require mzlib/defmacro) define-macro syntax-local-lift-expression (require racket/stxparam-exptime) make-rename-transformer syntax-local-require-certifier make-parameter-rename-transformer syntax-local-value define-syntax-parameter make-provide-transformer syntax-local-provide-certifier syntax-source local-expand/capture-lifts local-transformer-expand/capture-lifts syntax-local-lift-values-expression syntax-local-lift-module-end-declaration syntax-local-lift-require syntax-local-lift-provide syntax-local-name syntax-local-context syntax-local-phase-level syntax-local-module-exports syntax-local-get-shadower syntax-local-certifier syntax-transforming? syntax-local-introduce make-syntax-introducer exn:fail:syntax make-syntax-delta-introducer syntax-local-make-delta-introducer syntax-case define-syntax syntax-rules with-syntax syntax-position syntax-line syntax-column

Name: Anonymous 2011-08-10 19:44

>>42
Your answer shows that you're out of viable arguments. I will interpret it as your surrender.

Name: Anonymous 2011-08-10 19:48

The answer is clearly Fjölnir

Name: Anonymous 2011-08-11 0:06


*
"GRUNNUR"
;

Name: Anonymous 2011-08-11 7:35

>>1
CL is butt-ugly, Scheme doesn't even have a remotely usable standard - to get ANY (non-trivial) work done, you will get some sort of vendor-lock-in in all environments.

I suggest Erlang.

Name: Anonymous 2011-08-11 8:10

>>46
0/10

Name: Anonymous 2011-08-11 8:24

>>46
You might as well learn Prolog while you're at it.

Name: Anonymous 2011-08-11 9:47

>>48
Except that those languages are completely different.

Name: Anonymous 2011-08-11 10:09

>>49
Completely.

Don't change these.
Name: Email:
Entire Thread Thread List