Valhalla Legends Archive

I don't know, part of me would agree but I also recognize that learning Lisp once your familiar with C like languages requires you to forcefully forget everything that you thought you knew about programming. This could be avoided if Lisp was learned first, I suspect that other languages would be easier to learn then as well because you'll already be familiar with the infix notation through any experience with maths.

You also learn a concepts that carry over; though since learning Lisp I have found everything else to be lacking in several key areas: beauty, flexibility, power.

Even Python, which I was so enamored with in the past makes me want to pull out Scheme. In a lot of cases I find that I mock things up first in Lisp and then implement them in Python or whatever language I'm using, this leads to very elegant and reusable code if the language is powerful enough (of course sometimes I have to dumb it down a little because Python/Ruby/Perl/Whatever just aren't on the same level).

MIT teach Lisp to there students in a single lecture then build on the core concepts gradually, introducing different paradigms right in the same language. It seems clear to me that they do this for a reason.

I didn't have the advantage of learning Lisp first but I wish now that I had. Except that then I wouldn't know as many languages as well as I do.


I've looked at these languages before. Haskell is on my to do List along with SML (with Alice). Erlang from what I've seen is very impassive conceptually but the syntax makes my eyes bleed . I'll get around to it eventually. Io and Smalltalk have a lot in common but I do intend to look further at this language – I've heard some amazing things about it.


My problem is that OOP (especially class based) seems to be the biggest con I've ever come across. A way to spend hours and hours drawing intricate diagrams and interaction rather than solving an interesting problem.

People will argue that OO is at useful for creating types, but in dynamically typed languages this serves little actual point and I can get all of the abstract advantages of types in Lisp by constructing new types from primitives such as conses and procedures.

As an example I recently created a Token type for a project I'm playing with and it was far cleaner than the equivalent Ruby class. It was defined simply as a pair of function, one predicate and one action. Simple and flexible!

If the same thing had to be done in C++ or Java then the code would have been longer, uglier and not half as useful – these languages get in the way more than anything. Even in Ruby and Python it wasn't all too pretty IMO but it did take a small amount of code.


Note: I use Scheme myself, Lisp I expect you know is a family of languages, into which Scheme fits. Referring to Lisp rather than Common Lisp or Scheme is just a way to talk about all of them easily.

Later,

Mark.

Quote from: Banana fanna fo fanna on May 14, 2006, 06:01 PM
Oh, right, Python is cross-platform, and supports compilation to EXE.

Does bootstrapping the interpreter really count as compilation, and if so the solution isn't cross platform. You also fail to mention that exe's are several MB in size even for small applications.

Py2App does a marginally better job than Py2exe but this may be because Python is already available on all modern Macs. Maybe we could quote that as a reason to use it:


Python is readily available on computers running OS X and is becoming very common on Linux – most if not all major distros ship with it installed. Hewlett Packard also used to ship with Python installed on there Windows PCs, I don't know if they do anymore.


Don't get me wrong, Pythons a nice language and one I've spent a lot of time with but I don't think that this is really viable. I'm unaware of anyone shipping commercial applications in this way... in fact I've only seen one or two small free applications using this. Most people prefer to package Python in the installer.

Mark.

Lisp: this language more than any other will open up your head and show you the impossible. Some of the techniques that you'll learn are amazing and will translate wonderfully into some of the more powerful languages out there; others simply aren't possible outside of Lisp. What Lisp excels most at is solving hard problems, elegantly.


It's been highly regarded in academia and research labs all over the world for a very long time and some of the most intelligent and influential programmers have raved about it.

Eric Steven Raymond had this to say about learning Lisp...

"LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot."


There are a few other languages that you might want to look at, as mentioned Python is a pretty nice one. There's another that I'm less familiar with but am very impressed by, Ruby.

There's a great buzz right now about how Ruby may be the next Java (I'm sure they mean in popularity, not ineptitude). I think this may largely be due to the fact that its creator, Matz was at least aware of Lisp.

Some of these ideas make the supposed correlation between OO and code reuse laughable to put it lightly – I'm referring here to high-order functions and alike.

There are other very interesting languages such as Oz and Io.

Io is amazingly simple and beautiful. I expect it to become popular very soon and replace Lua in most embedded applications, but Io is powerful and complete enough to compete with heavier languages.

http://iolanguage.com/


Oz is about as perfect a language I've seen for distributed programming – networking and concurrency is made seamless and this is no easy task. Aside from there is a production quality implementation available for free at:

http://www.mozart-oz.org/


The down side to these is that they're current almost undocumented in comparison with other languages. This is a sad fact and a common problem with a lot of good languages that "no ones" ever heard of.


You have to remember that language is about expression, not about how close you work to whatever hardware your running or how likely you are to get a job from it.

For a first language I would put it to you all that this quality should be the most important.


These other languages wont teach you as much as Lisp IMO, but they will help you solve [boring] everyday problems. This might be what you're looking for in some situations so they're worth learning just for that.


If you really want to see which languages are best, look at the languages clever hackers are using and what they're doing with them.


It's a good idea to look around before committing. While your doing this be very weary of people all saying the same thing, there's usually a stupid reason for it like "my friends used it", "I learned it in School" or "I needed a job and I think programming was as good as any" etc.

Frankly anyone who tells you that C++, Java and there derivatives are good languages to learn at any point is stuck in the same realm as the ever-popular pointy-headed boss.

I'd go so far as to say there heads are lodged right up there own asses.



Take your time, pick a language that's fun and interesting, and choose for yourself!


Take care ,

Mark.

Since this thread one and the redirect may diverge in the listings at a later date I thought it prudent to post the link to what else was said here. It's been moved to an off subject forum and does diverge from the original topic so may not be what your looking for (still I don't agree with it's placement).

http://forum.valhallalegends.com/index.php?topic=14222.0

Mark.

Quote from: tA-Kane on February 09, 2006, 10:21 AM
I fail to see how recursion is "dog-slow", when for every time through, you must still set up and break down the structures which you used in order to create a non-recursive algorithm.

Have to agree here even though [most] compilers don't optimize recursion it doesn't make it slow. Recursion lends itself more naturally to a lot of different tasks, often more flexibly. In general recursive code is easier to read because you avoid state change – state changing is a performance hit on it's own, but Has been highly optimized.

Recursion helps avoid this state change and prevent the programmer from having to set up intermediate data structures to hold the results, rather than using the return value of a function .

Either way, the simplicity of expression should be reason enough to use recursion where appropriate.

Enjoy,

Mark.

Quote from: tA-Kane on February 07, 2006, 08:52 AM
Let's say I've passed my program a directory that it needs to search all files and subdirectories for anything that matches a specific filename. It needs to be POSIX-compliant.

After about two hours of searching the 'net using google, I've come up with little as far as results. The best I can come up with is that fopen() will fail and set errno to EISDIR, if you do not try to open a directory with write access. With that in mind, how would I get the names of all entities in a directory? Or is there another way to do this, which I am simply too blind to see?

I did find this nice little function, but it appears (according to the read) to be only for BSD.

I would like it to be as easy as calling FindFirstFile/FindNextFile/FindClose using the WinAPI, but again, sadly that's not POSIX compliant. 

Any help would be appreciated!

Not really about how to access a dir, Kp pretty much has that covered there . Of course there are other ways but they're less cross platform such as though system calls so you should probably ignore them.

Anyway, I'd like to offer a little suggestion about searching directories (or trees in general). I've found that the best technique for searching this kind of structure is through recursion, the code will be a lot easier to follow than if you had loops & nested-loops & nested-nested-loops...

You've likely figure this much out already but just incase you haven't thought it worth mentioning just incase.

Mark.

Quote from: MyndFyre on February 07, 2006, 02:57 PM

Quote from: netytan on February 07, 2006, 02:51 PM
*With a set of constants the application of a function/operator will result in the same results; this enables you to remove the computation from the program and replace if with those constants.

That's true, but we preserve handling code for '/' and '^' in CheckRevision code now "just in case" Battle.net decides one day to use those operators.  Typically the same strategy is used in these kinds of cases; constants can get outdated.  Algorithms, however, generally stay the same, even across versions.

Not so, you can't change the constants without changing the algorithm because their values are determined by it. The fact this part of the algorithm generated a constant access order means we can remove the computation completely there-by giving the computer less work to do.

If the algorithm were to change then it would yield the wrong results regardless of if you used constants or used the current algorithm to generate them each time – thats just how it works, you have to role with the punches. Write good code now and if it changes write good code again. Leaving things open incase one day things do change means you'll never have anywhere near optimal code .

Maybe I misunderstood.

Ah well, take care mynd .

Mark.

Not to be offensive to the venerable Shout but can i cite this as an argument against OO . If your talking about my code then I don't know but Yegg tested them – personally I know nothing about this Battle.Net thing but code above works perfectly from what I've been told, and removed a lot of arbitrary computation*.

Take care,

Mark.

*With a set of constants the application of a function/operator will result in the same results; this enables you to remove the computation from the program and replace if with those constants.

Quote from: Zakath on February 04, 2006, 07:57 PM
I can say that while his posting style may ruffle some feathers, I like the fresh perspective.

thanks Zakath

Quote from: Banana fanna fo fanna on February 05, 2006, 04:19 PM
...or pushing a hidden Lisp agenda!

Or just sharing high quality code banana . So some of that code is Lisp. If you don't wana use it don't .

Quote from: Skywing on February 02, 2006, 07:57 PM
You still have to keep track of allocations/references even in a GC language, though.  Especially with things like multithreaded programs or objects with explicit reference counts, you often still end up with the same having to remember to release objects as you would with just deallocating memory in large, non-trivial programs.

Tools for doing things like finding or tracking memory leaks have also come as long way too.  For instance, in Windows, I can use things like umdh and pageheap to quickly discover and investigate memory leaks in a conventional non-GC program.  Due to the deferred deletion / implict deletion nature of GC-based languages, such tools are often much less effective in discovering problems there.

I would submit that GC doesn't really absolve you of having to deal with resource management in many real world cases (non-trivial programs), and a lack of explicit control over resource referencing and deallocation makes non-trivial reference count/leak bugs in GC-based languages more difficult to find than in a traditional non-GC program written in a language like C.

(This has been my observation and experience given debugging problems in both cases.)

Certainly, your experiences may vary, but I don't believe that GC is all that it is cracked up to be given my experiences.

Thats understandable, I personally have never had to worrry about managing resources myself in these a languages. Occasionally I've called 'del' in Python etc. but not for any real reason it just made things clearer at some point.

Reference counting in Obj-C was pretty fun for a while because it's an interesting way to do things – rather than releasing data explicitly you manage a reference counter or mark it for auto release when every object with a  reference is done with it.

I don't know what languages you've used which have GC but none today should make you do that. Letting the GC handel memory is in general much better, you can't miss anything and so don't have go to the hassel of looking for leaks.

Most languages allow you to book when the GC will activate but any relatively decent GC should be sufficient for all but the very most demanding programs, likely all being run on a PC, and then IMO they should be largely written in ASM when speed becomes that much of an issue, or compiled from a dynamic language (if it supports native code compilation) and cleaned there.

Mark.

Quote from: Warrior on February 02, 2006, 04:48 PM

Quote from: netytan on February 02, 2006, 03:44 AMit just becomes too limiting. It's also not comparable with C++ for speed yet, though it will prevent a lot of memory leakage in your pants.

Just jesting guys,

Mark.

The programmer should prevent the leak, not the language.
Re-read your own posts.

Oh what a purist you are Warrior, never in my post did I say that it's the languages fault and not the programmers. Weather or not you like it memory management is much safer & cleaner than managing it yourself – take into account that most none trivial software written in this way contain a number of such bugs.

When I do want to manage my own resources I'll use ASM and get much more control over whats going on in the program, then link this in if that's it's purpose. The best of both worlds .

You're very welcome to manage the memory yourself and gain nothing from it. If you count longer and more bug riddled programs that run marginally faster for most cases* a gain then thats up to you but having the language do it for you doesn't place blame with the language or the programmer, get over it already.

If anything removing any source of bugs makes it the programmer more responsible for writing bad code, there are fewer excuses .

I personally would be much happier writing smaller more stable programs which are more or less guaranteed not to leak than writing slightly faster programs at the expense of these things creeping in [as they invariably do].



On a different note BrainFuck fans may be interested in WhiteSpace, a programming language based entirely around the characters we can't see lol. That said it's pretty fun embedding white space programs into others for a laugh. Running the program as language x and it'll do one thing, use white space and it'll do another. There's no real point but it's interesting all the same.

http://compsoc.dur.ac.uk/whitespace/

Here's an example of Hello world written using "whitespace",
http://compsoc.dur.ac.uk/whitespace/hworld.ws

Later,

Mark.

* GC has been around for a very long time (It first emerged in use in the mid 1950's and is under constant research & development. The result is that GC has gotten to the stage where it's efficient, fast and reliable.

Quote from: Warrior on February 02, 2006, 01:44 PM
I'd opt for D or any language with GC if that's the case.
But I usually opt for "It's the programmers fault not the language" and just fix my code,
but that's just me.

Worrior, I did NOT say that it was the languages fault – no language is gonna make a bad programmer a good one. I just told you that languages vary in power, and they do, you should probably re-read my posts if you didn't get it .

Mark.

Say the big tough C++ programmers . I used Python for 4 years (along with other stuff) and really enjoyed it until recently, it just becomes too limiting. It's also not comparable with C++ for speed yet, though it will prevent a lot of memory leakage in your pants.

Just jesting guys,

Mark.

Quote from: UserLoser on February 01, 2006, 08:07 PM
Is it possible netytan is someone we've seen in the past trying to come back with a "boom?"

Well User, I can unequivocally say no to that because I've never posted on this forum before yesterday. You're welcome to check but you'd be wasting time.

Mark.