* Haskell is the programming tool of choice for discriminating hackers.
* Dylan is a fine programming tool for many applications.
* C# is for implementing slow, unsafe programs slowly
It's not "Functional vs. OO". Object-orientied and functional programming paradigms co-exist together happily. They are not mutually exclusive at all. Dylan, a descendant of Lisp, is object-oriented from the ground up... much more so than Java. In Dylan, primitive types are objects, methods are objects, even classes are objects. But Dylan still supports lambda functions, map, curry, etc. for functional programming.
>
>Don't be silly. This is *exactly* what Common >Lisp was designed for.
>
I stand by my original assertion. You might want to read this paper which describes the early history of Lisp:
http://www8.informatik.uni-erlangen.de/html/lisp /h istlit1.html
You also might want to read the Purpose page of the book "Common Lisp the Language":
http://www.math.uio.no/cltl/clm/node6.html
No doubt that Lisp is one of the great programming languages of all time. But still it wasn't designed for systems programming and commercial software development. Dylan is basically a cleaned-up, fully object-oriented descendant of Lisp that has infix syntax and a powerful module and exception system. A Dylan entry won second place in the ICFP 2001 Contest. (See the page http://www.hoult.org/~bruce/dylan-hackers.html for more info about the Dylan entry.)
The ICFP entry was written with the open source version of Dylan for unix, Gwydion Dylan. http://www.gwydiondylan.org. For people that want to help improving the compiler, there are plenty of opportunities. It's a great compiler already, but there are still plenty of advanced optimizations that one could implement. Both major Dylan compiler implementations are written in Dylan themselves so the code is easy to understand.
Another implementation of Dylan for Windows by Functional Objects has an advanced IDE, and supports the Win32 API, COM, Corba, etc. Like Gwydion Dylan, it produces very fast code.
Speed of completion is almost always important in real life... because time is money.
Programs written in functional programming languages (using the term broadly to include Lisp, Dylan too) not only can be written faster, they are more likely to have the "stability, elegance, and beauty" qualities which you mention.
I'm currently doing a cross-platform project in Python with PyQt.
Compared to C, C++, and Java, Python is cool and a pleasure to use... but language-wise, it's not on the same level as Dylan (one of the languages that Norwig compares). Dylan is considerably better designed and more powerful... and Dylan has real compilers. If Dylan has cross-platform GUI libraries, I would definitely be using Dylan.
For a redesign of Lisp that is actually better (at least for the unwashed masses), see... Dylan. Dylan is object-oriented from the ground up, has infix syntax, has hygenic macros, has a flexible module system, and has a native code compiler...
Perl is leatherman tool... but imagine the leatherman tool just growing and growing until finally it so confusing and awkward to that it isn't useful anymore. To me, that describes Perl. God... what a mess.
The language just makes me shake my head... There are so much better designed languages out there for general purpose programming. Languages with an elegant and very powerful core. Languages whose libraries are written in the language itself. Languages who have real garbarge collection, not lame-arse reference counting. Languages who real have compilers. Languages that did just happen, but were planned. Dylan, Scheme, OCaml to name a few.
The choice of programming language significantly affects the security (and quality) of the software in question by elimination of whole classes of errors. Buffer overflows are just not possible in the more abstract programming languages such as Lisp, Dylan, Sather, Eiffel, Cecil, ML, OOCaml, and others. Pointer or memory management problems such dangling pointers or memory leaks are not possibilities either.
That covers the most common programming errors in C/C++. In C/C++, the programmer manipulates raw addresses and allocates and deallocates memory manually. In the other languages, the programmer doesn't have access to raw addresses or manipulate memory directly, so the programmer can't cause crashes and neither can an opponent.
This is all obvious... but no one seems to learn it.
Most of these language have very efficient implementations for them... meaning that they have compilers that can produce code that performs in the neighborhood of C code (or sometimes better). And these languages from the Lisp or functional families are much more productive than C/C++.
> However, Dylan's infix syntax (highly readable
> is a matter of opinion) tosses out the ability
> to write macros the way one can in Lisp
Dylan has a hygenic macro system. It's quite capable, though maybe a little burdened by the infix syntax of Dylan. (By the way, Dylan started out as a prefix syntax language, and later for a while, had both infix and prefix versions of essentially the same language).
I would agree that Lisp is slightly more powerful than Dylan. But Dylan has 9/10 the power of Lisp and is very cleanly designed and has many cool ideas. It's a great language for begineers, but at the same time, Lisp lovers coud live with it too. Don't forget that Dylan was designed by people who were experts in Lisp.
Dylan fixes near all the complaints that I have seen posted here about Lisp:
Dylan is fully objected-oriented from the ground up.
Dylan has highly-readable infix syntax.
Dylan has a module system.
Dylan has a sophisticated exception handling system.
The complaint that Dylan does not fix is the small user base. Unfortunately Dylan has a much smaller user base than even Lisp. But lack of other users should not stop a true geek.
> MIT undergrads could hack it on a student
> project but when applied on an industrial scale
> the result was utter confusion. The more someone
> likes multiple inheritance the more difficult
> it is to decipher their code.
Multiple inheritance is great. The problem is how the object-oriented language that became the most popular (C++) implemented it, which makes it a nightmare in that language. Other programming languages don't have a problem with multiple inheritance.
>
> C is still the high-level language that produces the fastest code.*
>
CMU Common Lisp performs better for some number crunching. Dylan is fast also. Also I think some of the functional languages such as ML perform quite well.
And all of these languages are much higher-level and more productive than C.
Not that Lisp doesn't have most of those features... but I think that people that haven't been initiated into Lisp's greatness will find these features more palatable and understandable in Dylan.
Dylan on the other hand is a heavily-mutated descendant of Lisp which is fully object-oriented, has infix notation, and a module system. In Dylan, after writing a program with no type information, the programmer can later optimize his program for more efficient execution by supplying type information to the compiler. Nearly all entities in Dylan (including functions, classes, and basic data types such as integers) are first class objects. Additionally Dylan supports multiple inheritance, polymorphism, multiple dispatch, keyword arguments, object introspection, and many other advanced features.
Compiled and Interpreted YES
A good standard library YES
Truly Object Oriented (like Smalltalk) YES (In Dylan even methods are objects)
Support flexibility YES (Dylan has hygenic macro system)
I once had a mid-level undergraduate programming class where a very small assignment had to be implemented in Lisp and then again in Java. After the completing the assignments, about 50% of students thought Lisp was a better language, while about 50% thought Java was a better language. I was surprised at how many students ended up thinking that Lisp was a better language, even though I'm sure the students had had much more previous experience to C, C++, and Java.
I'm pretty sure that if Dylan had been taught instead of Lisp in the class, over 90% of the students would have preferred Dylan over Java. (Dylan is descendant of Lisp with a cleaned up design, and is a lot easier for beginning programmers to understand than Lisp.)
But the bigotry present in the industry against non-C-like languages is very hard to overcome, so Lisp and Dylan and the functional languages will remain obscure for now, though they are dramatically much more productive.
> Actually, the best code is often written
> in very low-level languages, like C
> and assembly
False! It's very hard to write good code in low-level languages. Low-level languages just don't provide the proper constructs for organizing code clearly. For example, in C, functions can only return one value (at least directly). That's totally ridiculous. A general purpose language in the year 2001 should definitely allow multiple return values.
How about memory management? In complicated systems, managing memory manually leads to messy code.
How about exceptions? Exceptions make code cleaner. C doesn't even have exceptions, while the exception mechanisms in C++ and Java are lame compared to those in a language such as Dylan.
Slashdot Mirror
* Haskell is the programming tool of choice for discriminating hackers.
* Dylan is a fine programming tool for many applications.
* C# is for implementing slow, unsafe programs slowly
It's not "Functional vs. OO". Object-orientied and functional programming paradigms co-exist together happily. They are not mutually exclusive at all. Dylan, a descendant of Lisp, is object-oriented from the ground up... much more so than Java. In Dylan, primitive types are objects, methods are objects, even classes are objects. But Dylan still supports lambda functions, map, curry, etc. for functional programming.
>
p /h istlit1.html
>Don't be silly. This is *exactly* what Common >Lisp was designed for.
>
I stand by my original assertion. You might want to read this paper which describes the early history of Lisp:
http://www8.informatik.uni-erlangen.de/html/lis
You also might want to read the Purpose page of the book "Common Lisp the Language":
http://www.math.uio.no/cltl/clm/node6.html
No doubt that Lisp is one of the great programming languages of all time. But still it wasn't designed for systems programming and commercial software development. Dylan is basically a cleaned-up, fully object-oriented descendant of Lisp that has infix syntax and a powerful module and exception system. A Dylan entry won second place in the ICFP 2001 Contest. (See the page http://www.hoult.org/~bruce/dylan-hackers.html for more info about the Dylan entry.)
The ICFP entry was written with the open source version of Dylan for unix, Gwydion Dylan. http://www.gwydiondylan.org. For people that want to help improving the compiler, there are plenty of opportunities. It's a great compiler already, but there are still plenty of advanced optimizations that one could implement. Both major Dylan compiler implementations are written in Dylan themselves so the code is easy to understand.
Another implementation of Dylan for Windows by Functional Objects has an advanced IDE, and supports the Win32 API, COM, Corba, etc. Like Gwydion Dylan, it produces very fast code.
> Other people may already have some
> experience using SDL with other
> interpreted languages?
Are you implying that Scheme is an interpreted language? I think there are Scheme compilers.
Because the entries written in functional programming languages always win. ;-)
Speed of completion is almost always important in real life... because time is money. Programs written in functional programming languages (using the term broadly to include Lisp, Dylan too) not only can be written faster, they are more likely to have the "stability, elegance, and beauty" qualities which you mention.
Well I suspect that a team using a ML dialect will win because they will have so many teams entering, but I'll be rooting for the Dylan entry.
I'm currently doing a cross-platform project in Python with PyQt. Compared to C, C++, and Java, Python is cool and a pleasure to use... but language-wise, it's not on the same level as Dylan (one of the languages that Norwig compares). Dylan is considerably better designed and more powerful... and Dylan has real compilers. If Dylan has cross-platform GUI libraries, I would definitely be using Dylan.
For a redesign of Lisp that is actually better (at least for the unwashed masses), see... Dylan. Dylan is object-oriented from the ground up, has infix syntax, has hygenic macros, has a flexible module system, and has a native code compiler...
Adtech Data Link Simulators: http://www.adtech-inc.com/products/sx.asp
"Adtech SX series Data Link Simulators create the same delay and error characteristics caused by long distance terrestrial and satellite data links."
Perl is leatherman tool... but imagine the leatherman tool just growing and growing until finally it so confusing and awkward to that it isn't useful anymore. To me, that describes Perl. God... what a mess.
The language just makes me shake my head... There are so much better designed languages out there for general purpose programming. Languages with an elegant and very powerful core. Languages whose libraries are written in the language itself. Languages who have real garbarge collection, not lame-arse reference counting. Languages who real have compilers. Languages that did just happen, but were planned. Dylan, Scheme, OCaml to name a few.
The choice of programming language significantly affects the security (and quality) of the software in question by elimination of whole classes of errors. Buffer overflows are just not possible in the more abstract programming languages such as Lisp, Dylan, Sather, Eiffel, Cecil, ML, OOCaml, and others. Pointer or memory management problems such dangling pointers or memory leaks are not possibilities either.
That covers the most common programming errors in C/C++. In C/C++, the programmer manipulates raw addresses and allocates and deallocates memory manually. In the other languages, the programmer doesn't have access to raw addresses or manipulate memory directly, so the programmer can't cause crashes and neither can an opponent.
This is all obvious... but no one seems to learn it.
Most of these language have very efficient implementations for them... meaning that they have compilers that can produce code that performs in the neighborhood of C code (or sometimes better). And these languages from the Lisp or functional families are much more productive than C/C++.
> However, Dylan's infix syntax (highly readable > is a matter of opinion) tosses out the ability > to write macros the way one can in Lisp Dylan has a hygenic macro system. It's quite capable, though maybe a little burdened by the infix syntax of Dylan. (By the way, Dylan started out as a prefix syntax language, and later for a while, had both infix and prefix versions of essentially the same language). I would agree that Lisp is slightly more powerful than Dylan. But Dylan has 9/10 the power of Lisp and is very cleanly designed and has many cool ideas. It's a great language for begineers, but at the same time, Lisp lovers coud live with it too. Don't forget that Dylan was designed by people who were experts in Lisp.
Dylan fixes near all the complaints that I have seen posted here about Lisp:
Dylan is fully objected-oriented from the ground up.
Dylan has highly-readable infix syntax.
Dylan has a module system.
Dylan has a sophisticated exception handling system.
The complaint that Dylan does not fix is the small user base. Unfortunately Dylan has a much smaller user base than even Lisp. But lack of other users should not stop a true geek.
> MIT undergrads could hack it on a student
> project but when applied on an industrial scale
> the result was utter confusion. The more someone
> likes multiple inheritance the more difficult
> it is to decipher their code.
Multiple inheritance is great. The problem is how the object-oriented language that became the most popular (C++) implemented it, which makes it a nightmare in that language. Other programming languages don't have a problem with multiple inheritance.
>
> Python's tuples let you do exactly this.
>
But in a language such as Dylan, you can directly return multiple values:
let (quotient, remainder) = 2 / 3;
And this can be efficiently implemented by the compiler.
> And in C/C++, it's not always completely
> unreasonable to define a struct type just for > returning from a function.
It's also a pain in the arse.
>
> A function that returns more than one value isn't a function.
>
Then what would you call it? It sure is useful.
In Dylan you can do something like:
let (quotient, remainder) = 2 / 3;
>
> C is still the high-level language that produces the fastest code.*
>
CMU Common Lisp performs better for some number crunching. Dylan is fast also. Also I think some of the functional languages such as ML perform quite well.
And all of these languages are much higher-level and more productive than C.
Not that Lisp doesn't have most of those features... but I think that people that haven't been initiated into Lisp's greatness will find these features more palatable and understandable in Dylan.
Dylan on the other hand is a heavily-mutated descendant of Lisp which is fully object-oriented, has infix notation, and a module system. In Dylan, after writing a program with no type information, the programmer can later optimize his program for more efficient execution by supplying type information to the compiler. Nearly all entities in Dylan (including functions, classes, and basic data types such as integers) are first class objects. Additionally Dylan supports multiple inheritance, polymorphism, multiple dispatch, keyword arguments, object introspection, and many other advanced features.
Dylan has all the features you are interested in:
Compiled and Interpreted YES
A good standard library YES
Truly Object Oriented (like Smalltalk) YES (In Dylan even methods are objects)
Support flexibility YES (Dylan has hygenic macro system)
I once had a mid-level undergraduate programming class where a very small assignment had to be implemented in Lisp and then again in Java. After the completing the assignments, about 50% of students thought Lisp was a better language, while about 50% thought Java was a better language. I was surprised at how many students ended up thinking that Lisp was a better language, even though I'm sure the students had had much more previous experience to C, C++, and Java.
I'm pretty sure that if Dylan had been taught instead of Lisp in the class, over 90% of the students would have preferred Dylan over Java. (Dylan is descendant of Lisp with a cleaned up design, and is a lot easier for beginning programmers to understand than Lisp.)
But the bigotry present in the industry against non-C-like languages is very hard to overcome, so Lisp and Dylan and the functional languages will remain obscure for now, though they are dramatically much more productive.
Why should you have to pack the items that you want to return into a struct? That's lame.
C was okay considering the time period in which it was developed (late 60's)... but it's time to move onto more productive languages.
> Actually, the best code is often written
> in very low-level languages, like C
> and assembly
False! It's very hard to write good code in low-level languages. Low-level languages just don't provide the proper constructs for organizing code clearly. For example, in C, functions can only return one value (at least directly). That's totally ridiculous. A general purpose language in the year 2001 should definitely allow multiple return values.
How about memory management? In complicated systems, managing memory manually leads to messy code.
How about exceptions? Exceptions make code cleaner. C doesn't even have exceptions, while the exception mechanisms in C++ and Java are lame compared to those in a language such as Dylan.