G
gwowen
'"X is evil" considered harmful' ?
'"X is evil" considered harmful' ?
M
Mike McCarty
Lisp's syntax is not unusual - it's simple. Extremely simple and intuitive..
Lisp as a basic language is small, very small. You can teach both the syntax and all of the basic constructs in ~1 hour to a reasonably competent CS student. Enough to write any algorithm a first-year student is likely to write. I can't think of another language where that is even theoretically possible.
I'm sort of old-fashioned I suppose, but what does a first-year CS student need with fancy GUIs? Honestly, they just confuse the issue. Lisp is an interpreted language so an interpreter prompt is really all you need (okay, a Lisp-aware text editor like emacs would be nice too).
My first college CS course was based on Scheme (a LISP variant). At the time I thought it was odd, but now I consider it an ideal first-year-CS language. You don't spend time worrying about syntax, IDEs, etc. You worry about algorithm design and correctness. As it should be.
M
Man-wai Chang
'"X is evil" considered harmful' ?
I agree having to manage memory allocation and data typing yourself
isn't really evil, but inconvenient only...
--
@~@ You have the right to remain silence.
/ v \ Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora 15 i686) Linux 3.2.6
^ ^ 23:06:01 up 6 days 10:03 0 users load average: 0.00 0.01 0.05
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
M
Miles Bader
Nick Keighley said:
Wait, this is being used as a defense of _python_? *boggle*
-miles
G
Guest
'"X is evil" considered harmful' ?
indeed!
G
Guest
ok it's simple. It's /also/ unusual. One mans "intuitive" is another mans.... But we have fallen into pantomime mode.
Common Lisp may have a very small core but I've never found it particularly easy to identify.
probably. But then basic C or Pascal or Python wouldn't take too long either.
really? I suspect bit banging is a bit difficult in core Lisp. Knuth had a reason for using pseudo-assembler.
What would be difficult in Pascal or Python?
engage their interest. real world programming actually has to deal with such things. When I was talking about beginner languages I wasn't necessaily thinking of CS students.
no. It *may* be an interpreted langauge. The CL standard actually requires a compiler. Stalin Scheme is one of the more aggressive whole program compilers in existence.
never quite got the enthusiasm for interpreters. I've programmed in Python but I've never understood why interpreters are super cool. On modern hardware compilers are pretty quick too.
I've learned, used and like Scheme.
[the new google interface seems to have duplicated the entire post here :-( ]
R
Rui Maciel
Nick said:
Every programming language has an unusual syntax to those who never had any
contact with it.
Then there is Scheme.
I believe there are some lisp bindings for some GUI toolkits. And there are
some CGI interfaces for Lisp floating around.
http://en.wikipedia.org/wiki/Mod_lisp
http://www.clisp.org/impnotes/fastcgi.html
I never used any of them, though.
Rui Maciel
G
Guest
I can program in a Lispy language (scheme).
Ada, Pascal, C, C++, Java, C#, Python
all have pretty similar syntax. Lisp doesn't. But this becomes tedious.
I was assuming "Lisp" meant Common Lisp. Standard Scheme is indeed tiny.
that's my point. "floating around" doesn't really cut it.
M
Man-wai Chang
Lisp's syntax is not unusual - it's simple. Extremely simple and intuitive.
I used Golden Common LISP and PROLOG. Their main selling point are
recursion. It would be a nightmare to code procedural codes.
Give us user-interface objects and database functions first for a
programming language to be really useful.
--
@~@ You have the right to remain silence.
/ v \ Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora 15 i686) Linux 3.2.6
^ ^ 23:18:01 up 7 days 10:15 0 users load average: 0.00 0.01 0.05
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
I used Golden Common LISP and PROLOG. Their main selling point are
recursion. It would be a nightmare to code procedural codes.
Give us user-interface objects and database functions first for a
programming language to be really useful.
--
@~@ You have the right to remain silence.
/ v \ Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora 15 i686) Linux 3.2.6
^ ^ 23:18:01 up 7 days 10:15 0 users load average: 0.00 0.01 0.05
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
G
Guest
C, C++, Python, Perl all support recursion. What language doesn't? Some older BASICs?
<snip>
B
BGB
being most of the way through college as a CS major, I have seen the
following taught in classes:
C, C++, ASM, Java, VB.NET, and C#.
observation:
students appear to have an easier time with Java, C#, and VB.NET, than
they do with C, C++, and ASM.
the VB class was IMO kind of a joke, as the book and assignments were
basically a bunch of screen-shots (of Visual Studio) with arrows (click
here, drag this there, type in this code fragment there, ...). sometimes
with brief side-notes and explanations between the screen-shots (extreme
critical thinking this is...).
most of the General-Education classes are considerably much harder.
as for myself, I started at first, long ago, with BASIC, then learned C
and ASM, and learned other stuff from there (but mostly use C and some
C++ and ASM). have messed with Java and C#, but never really gotten into
them (neither really offers much personally in my main areas).
I personally dislike Python, finding it in most ways to be rather hideous.
I have my own projects, and my own custom scripting language (ECMAScript
based), though...
or such...
B
BGB
kind of funny is I started getting into programming a little while
before Java came out (I started messing with a lot of this stuff
sometime around 3rd grade IIRC).
some-odd years later, amid its time of huge hype, I already knew C, and
messed around with Java, but didn't really like what I saw:
it was very painful/awkward to use, and slow as hell...
they have since added a number of usability-improving features (inner
and anonymous classes, "import static", ...), and made Java much faster,
but I still find it kind of awkward and lame.
granted, I did recently go and look back at some code (in C) I had
written long ago (back when I was in high-school, ~ 12 years ago now),
observed that the quality was actually fairly poor by my current standards.
in many areas, a lot of the same code remains intact, albeit often in
heavily-modified forms.
sadly though, much time has gone by and little notable has happened...
B
BGB
side note: the code was from 12 years ago. I finished high-school ~ 9
years ago.
B
BGB
Maybe some other things would be good for them too.
http://www.codingthewheel.com/game-dev/john-carmack-script-interpreters-considered-harmful
I'm not trying to start a language flame war, honestly. I'll let this
guy do it for me.
Python has some interesting features, but I tend to think that some of
that might be difficult for beginners. For example, I agree with you
that strong typing is a good thing.
If Python is "good", whatever that means, then why isn't Lisp,
"better"? http://xkcd.com/224/
ironically, Carmack is a bit of a personal influence of mine (and I had
learned a fair amount from his code over the years).
I also implement scripting VMs, and have my own scripting language.
the thing is arguably a bit "heavy" by scripting-language terms (in
terms of language and VM complexity), as it is mostly AS3 like at
present (similar syntax, ECMAScript-based, with importing/packages,
optional classes and type-annotations / static-types, in addition to
Prototype OO and dynamic types, ...).
it also incorporates some concepts from C and C++ as well (namely:
optional pointer-based types, pass-by-value classes / "value classes",
and RAII, ...). it isn't perfect though (the pointers are internally
represented as boxed objects, ...).
it started out closer to a straight mix of JavaScript, Scheme, and Self,
but over time began incorporating ideas from Java, AS3, C#, C, ... into
the design.
this wasn't strictly for performance reasons, but more often for
"scalability" reasons, as what works well with a small amount of code
isn't necessarily good with a bit more code.
another major issue was trying to make the C FFI reasonably good, and a
good way to help here is to lessen the borders between the Script VM and
the native C code (it is a lot easier to share data when ones' VM is all
like "yeah, I understand structs and pointers..."). this is mostly
because I don't particularly like writing boilerplate.
performance isn't really great (vs C or C++), but is mostly tolerable
for most stuff (albeit most "heavy lifting" is done in C and C++, script
code is mostly for "misc" stuff).
I had recently done a little fiddling with writing a new JIT for the
thing though (as-is, currently execution is mostly built on a mix of
threaded code with some limited/fragmentary native code-generation).
threaded code is a bit faster than a naive "big switch()" interpreter
(where the interpreter is a loop feeding opcodes into a giant "switch()"
block), but "it could still be a bit faster".
granted, in my case, the video card still seems to be a much bigger
bottleneck than the scripting VM's performance, hence why speeding it up
hasn't been a huge priority.
or such...
B
BGB
hence, why although I did implement a Scheme variant at one point, my
next major language (implemented not long after), switched to a
JavaScript based syntax...
my current language is arguably a direct descendant though, although
there have been a number of changes over the years (some syntax, mostly
semantic).
yeah, and also most people showing up aren't exactly "blank slates" either.
yep.
although I don't necessarily entirely like "real world" based arguments
(which often boil down to "it is a dog-eat-dog world where people need
mountains of money to survive" or "it is a waste of time for programmers
to actually do anything or actually write code" or whatever), things
don't really exist in a vacuum either, and "what is the case?" and "how
can this be useful?" are fairly important.
so, yes, people may need to think about things like:
how easily can I do typical file IO task?
how easily can I access sockets?
how easily can I throw together a basic GUI?
....
kind of hard to pass off a language which does poorly in these areas
(among others).
well, it depends on how one draws the line.
as I see it, they aren't really exclusive, as one can have an evaluation
prompt and compile most things to native code easily enough.
for dynamic loading or interactive entry, short of having to include a
mountain of headers (one of several major killers for my "C as a
script-language effort"), one can actually compile things fairly quickly
(and get much better overall performance than with a plain interpreter).
a scripting language with a vaguely C-like syntax and a fairly strong C
FFI is "close enough" to being interactive entry of C.
likewise, given the headers are compiled to databases and loaded in
advance, it also avoids the huge delay of having to drag in a bunch of
stuff from headers in order to compile stuff (the compiler/VM may
instead simply retrieve the parts it needs).
I tested, and even running my VM from Linux/ARM, running inside QEMU,
running on Linux x86-64, running inside VMware, running on Windows 7,
the VM was still fairly quick and responsive (despite an apparently >
1000x slowdown, invoking GCC within the emulator, to compile pretty much
anything, took a *long* time...).
granted, I probably one of the few people who cares how quickly "eval"
runs, for sake of wanting to use it for some tasks in a soft real-time
3D engine type scenario (it need not just be fast enough for interactive
use, but also fast enough so that it can be used for things like world
event triggers and so on, without adversely impacting gameplay).
yes, yes, maybe "eval" isn't really "the right tool for the job", but
whatever...
agreed, I am not fond of emacs...
I liked Scheme, and even in my newer efforts, it isn't entirely dead
(even if given my language designs, people are prone to make accusations
of "blub" and whatever...).
G
glen herrmannsfeldt
(e-mail address removed) wrote:
(snip, someone wrote)
Even the BASIC GOSUB should allow for recursion.
Fortran added it in Fortran 90.
But even though those allow for it, many problems are easier
to write, and run faster, without using recursive calls.
Factorial and Fibonacci are two favorite examples of recursion
that, especially the latter, should be done without recursion.
Quicksort can be written simply with recursion, but not all
that much harder without it.
-- glen
(snip, someone wrote)
Even the BASIC GOSUB should allow for recursion.
Fortran added it in Fortran 90.
But even though those allow for it, many problems are easier
to write, and run faster, without using recursive calls.
Factorial and Fibonacci are two favorite examples of recursion
that, especially the latter, should be done without recursion.
Quicksort can be written simply with recursion, but not all
that much harder without it.
-- glen
B
BGB
but, the recursive Fibonacci function makes such a great benchmark...
why not have an algo where one can be like "fib(38)" or "fib(42)" and
measure how long it takes to complete?
granted, yes, one can have recursive selection-sort or similar, but it
is more complicated and doesn't have nearly as much time complexity.
otherwise, one can use bubble-sort of giant arrays, which, likewise,
requires allocating storage space for said array.
G
glen herrmannsfeldt
(snip, I wrote)
I suppose it is a good benchmark for function call overhead,
but not much else. Maybe also a test for tail recursion optimization,
but there should be better tests for that. (It isn't so bad if
you include a cache of previously computed values.)
-- glen
I suppose it is a good benchmark for function call overhead,
but not much else. Maybe also a test for tail recursion optimization,
but there should be better tests for that. (It isn't so bad if
you include a cache of previously computed values.)
-- glen
B
BGB
it depends on what is being measured.
if it is a dynamic language, it may also put a strain on things like
type-checking, accessing local variables and arguments, and performing
basic arithmetic.
in an interpreter, there is also the instruction dispatch overhead, ...
one can also alter it to perform other side operations in which to
benchmark, ... (like, a variant which does string operations or vector
arithmetic or similar).
or such...