| Il linguaggio Dylan ha dei significativi vantaggi teorici, ma in pratica penso venga usato pochissimo, e ha altri problemi. In programmi piccoli comunque la sua sintassi mi pare piuttosto comprensibile:
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=mandelbrot&lang=gwydion&id=0
E' un linguaggio analogo a Lisp ma con sintassi tipo Algol (cioe' come Pascal, C, Java, ecc.). Il suo essere un Lisp lo si vede dalla presenza di macro (ma un po' diverse da quelle del Lisp, credo siano meno potenti ma anche di uso piu' sicuro), ma lo si puo' vedere anche solo da due righe come queste nel codice di quel piccolo programma per il calcolo di un insieme di Mandelbrot:
Ci := (2 * y / as(<double-float>,h) - 1); byte-acc := ash(byte-acc,1);
Come si vede - 1 indica una sottrazione, mentre se non sono presenti spazi, come in byte-acc, allora esso e' un singolo identificatore e non equivale a byte - acc. Questo e' un dettaglio che vale anche in Lisp, ma in Lisp la sintassi sarebbe byte-acc per l'identificatore e (- byte acc) per la differenza, per cui mi pare piu' facile distinguere le due situazioni. In un certo senso in Dylan gli spazi mi sembrano ancora piu' significativi che in Python :-) | comments: Leave a comment  |
| >Forpedo is a preprocessor for Fortran 90 code, written in Python. It can handle some typical preprocessing tasks, like including code from one file in another, but it is mostly designed to provide advanced techniques to pre-Fortran 2003 versions of the language. In particular, there is support for C++ like generics (templates), and run-time polymorphism from Object-Oriented Programming (OOP) (click here for more details on OOP in Fortran). The output of Forpedo is pure Fortran code, which should work with any standard compiler.<:
http://www.macanics.net/forpedo/index.php
Just about 24 KB of Python code that reproduce an useful part of the differences between C and C++, and it can be improved a lot. Moral: "preprocessors" have to be written in a high level language, and not with C :-) Maybe in the next 10-20 years (with faster/more parallel computers) people will understand that compilers too, like a C compiler, are better written in a high level language, and not with C :-) An example: ShedSkin is written in Python. It's a bit slow, and it's not a real compiler, but it shows the way. | comments: Leave a comment  |
| This post contains nothing new, just some reflections. At the moment Python is the programming language I like most, but it's not perfect, and for some purposes is too much slow or unfit.
A person that likes to program, or programs to work, must keep learning new languages until he/she/shi decides to stop coding. There are several reasons for this: - New languages contain and represent new ideas, and the practical sides of computer science keep changing, so learning a new language allows you to keep up with them. - Learning something new keeps the brain flexible. - Different languages contain different ideas. Learning a good language changes the way you think. - Learning very different languages, like Prolog, Scheme, Haskell, Python, etc, hurts your mind in a good way, they stretches it. Even if you always work with just a language (like Java) learning very different languages teaches you new ways to think, lets you understand better some basic things of computer science, and later you will program better in the language that gives you a job too. I have read a similar idea years ago, but now I have ways to believe it.
I have followed some of the first mythic lessons by Abelson and Sussman: http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
To find a good Scheme I have tried many installations, some of them look terrible, they need keyboard access for everything, learning all those commands seems a lot of work. I don't know if I'll ever have the will and time to learn such editing. But I trust such people, that probably such work isn't wasted. Later I have found this good explanation: http://groups.google.com/group/comp.lang.scheme/msg/9f8fc18c7fc78696
What's good and bad about a language is context-dependent. If you're using mouse when you edit code, probably Lisp-family language isn't your choice. It still isn't your choice even if you're cursor-key oriented.
When I first saw a long-time Lisp programmer editing (and debugging) his code on Emacs it blowed my mind. His code was flying. Basically, once you get used to, you won't work on (and think on) per-character basis anymore. Instead, you work on per-expression. No matter how complex the expression is, spanning many lines or nested so deeply, you can treat the whole expression with a few keystrokes---e.g. cutting an expr, skip next two exprs, paste the original expr, then adjust the whole indentation; or sending a whole expression to interactive REPL and check the result; or factoring out a subexpression and turning it into a local function. You get a feeling you are grabbing the code itself, not the characters on the screen.
For your original question: probably it's easier to appreciate what's special in Scheme by shifting your viewpoint from a language user to a language designer---the former is to accept the language features as given and unchangeable, and tries to write all the solutions in it; while the latter first look at the problem, think about what language is suitable to describe the problem, then write the language using the base language.
Then I have found DrScheme: http://download.plt-scheme.org/drscheme/ This editor is practically usable, almost good, here the language is made as practical as possible, there is even a way to reduce the language to a subset fit for learning! So far I can't stand still the syntax with all those parenthesis. I am sure they are good for a machine but I can't believe they are good for a human too. Probably I'll need some months of exercise to digest them. In the past I have learnt a very good and modern dialect of Forth (for HP48 calculators), so I know I can learn a fully postfix notation (but Forth uses a stack and not a tree of brackets! Forth doesn't look much designed for human brains, but its syntax seems better than Scheme/CLisp ones still.
Scheme can theoretically be compiled to quite fast executables, there is a good but slow compiler, called Stalin, but in practice their programs when interpreted by DrScheme are slower than Psyco programs: http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=mzscheme&lang2=psyco Scheme may be seen as more flexible than Python still. Python designers have explicitly avoided excessive flexibility, like the macros. Later I have found another post that discusses about Python and Scheme, and some of their differences. It gives an interesting view on the situation: http://groups.google.com/group/comp.lang.scheme/msg/b5d2b2473beecd8a
> Pythonistas seem to be much more willing to share their code, and > engage in collaborative efforts than Schemers. This is also true for > Perl. I wonder why that is. Python is bursting at the seams with > modules, and there are frequent software offerings on > comp.lang.python.announce. Yet these kinds of announcements are rare > on Scheme and Lisp newsgroups.
I have looked at this too. Right now it seems there are more announcements in comp.lang.ada than here. I think I have an explanation for this: Of the scheme software I've downloaded, most has required tweaking to work on my scheme of choice (mzscheme). That's one thing. Another, far more important thing to my eyes, is that programs are written in very, very different styles. Scheme is suitable for functional, imperative, declarative, message-parsing and/or object-oriented styles, plus a couple of dozen that aren't invented yet. On top of that you get personal idiosyncrasies like all programmers have, so if a scheme program nevertheless is easy to read, it's probably because the author happens to use the same styles as you. (The lack of standard libraries is also a problem, although most non-trivial programs I've downloaded use slib.) So perhaps scheme's flexibility is it's greatest problem?
Like art, even very good art, programming is a balance and struggle between flexibility and constraints. If such balance is lost you can't write long and complex programs. | comments: Leave a comment  |
| http://scienceblogs.com/goodmath/2006/08/ultimate_spaghetti_coding_with.php
I have nothing new to add. I think there is progress in the way programming languages are used to work, but it's slow, and often it happens where you aren't looking.
Scheme and Lisp aren't "very nearly underpowered Lisps different syntax", they are different. Python explicitely refuses macros (and adopts some better syntax) because having standard ways to things is better for most people. 80% of programmers need a language simpler than Lisp. Elegance matters, but syntax and bounds matter too. Without bounds most people feel lost.
Different languages are fit for different people and different purposes. If you are a very good programmer working alone on a very complex field Lisp can be better than Python/Java/C++, but if are an average programmer, working in a firm with lot of other average programmers on a "boring" but very big software that need all the kinds of already made interfaces with tens of systems, then Java/C# may be the right choice.
Learning other languages like Haskell, Python, Lisp, helps to widen the mind of a programmer, but to work she/he has to use Java/C++/C#/PHP still. | comments: Leave a comment  |
|