| ||||||||
| Un altro sito di "code golfing", questo ha regole diverse e decisamente piu' elastiche, non si comporta sempre allo stesso modo ma in modo flessibile: http://golf.shinh.org/ C'e' anche una classifica dei linguaggi in base alla loro sinteticita', queste sono alcune entry: http://www.shinh.org/lranking.rb 1 GolfScript 2 Ruby 3 Perl 6 Python 7 C 14 J 23 D 32 Ada 40 Java 30 C++ C e' risultato piu' sintetico del D. Ada piu' sintetico di JAVA? J al 14esimo posto? Questi sono alcuni esempi di codice D (non creato da me): import std.cstream;void main(){dout.writef=din.toString.sort;} import std.stdio;char i;void main(){for(;gets=&i;)puts=gets=&i;} import std.stdio;void main(){for(int c,d,e;c=getchar,~d;e=d,d=c)putchar=(c|d) import std.stdio;void main(){foreach(x;[9,249,17,2,157,116,227,9 GolfScript non lo conoscevo, e' un linguaggio inventato per tale scopo, per giocare a code golfing! E' un interprete scritto in Ruby (il codice e' breve) e assomiglia ad una via di mezzo tra Python e Forth, dove gran parte delle istruzioni sono lunghe un carattere e sono pesantemente sovraccaricate a seconda del contesto. Sembra illeggibile, ma a differenza della maggior parte degli altri linguaggi esoterici questo e' progettato per permettere la scrittura di veri programmi, per quanto piccoli, per cui credo sia utilizzabile: GolfScript is a stack oriented esoteric programming language aimed at solving problems (holes) in as few keystrokes as possible. It also aims to be simple and easy to write. Short code is achieved by using single symbols to represent high level operations (such as map, join, array size, etc). Being stack based allows for functions and other manipulations to work without the need for explicit variables, however variables still exist and are useful for more complicated stack manipulations: http://www.darrenks.com/golfscript/synt | ||||||||
comments: Leave a comment   |
leonardo
|
|||||||||||||
January 16th, 2008
January 13th, 2008
| ||||||
| NewLisp e' un linguaggio di scripting abbastanza nuovo, in pratica e' una nuova variante del Lisp e Scheme: http://newlisp.org/ E' interpretato e la sua velocita' e' paragonabile a quella di Python (ma gli hash e gestione stringhe di Python sono piu' veloci). Elimina un bel po' di difetti di Scheme (che e' una versione ripulita del Lisp) (e hanno aggiunto solo pochi difetti, aggiungendo alcune inefficienze), e in effetti questo NewLisp e' un linguaggio molto gradevole, perche' hanno aggiunto tante cose utili nella pratica, e mi pare lo abbiano semplificato rendendolo perfino piu' semplice dello Scheme. Ha una IDE, grafica built-in, e' multipiattaforma, ecc. Per cui oggi questa e' la variante del Lisp che preferisco. Comunque non lo usero' perche' per i compiti di scripting Python e' piu' comprensibile, efficiente ed e' molto piu' diffuso. E d'altronde questo NewLisp e' interpretato (e probabilmente e' ben piu' lento di Psyco), per cui non posso usarlo dove serve la massima velocita' (dove ad esempio posso usare D). Alcuni frammenti di codice che mostrano la notevole eleganza del linguaggio: http://newlisp.org/index.cgi?page=Code_ Un esempio, per eseguire un "sort naturale" di stringhe:
(define (natural-sort l)
(let (natural-key (lambda (s) (filter true?
(flat (transpose (list
(parse s "[0-9]+" 0)
(map int (find-all "[0-9]+" s))))))))
(sort l (fn (x y) (< (natural-key x) (natural-key y))))
))
Che si usa: (natural-sort '("a10" "a2" "a1" "a14")) => ("a1" "a2" "a10" "a14") Comunque del codice analogamente sintetico puo' essere scritto anche in Python (nota: in Python le RegularExpression dopo essere state compilate vengono messe in una cache, per cui quello che segue non e' molto piu' lento che usare una re.compile):
>>> l = ["a10", "a2", "a1", "a14"]
>>> from re import split
>>> sorted(l, key=lambda s:[int(p) if p.isdigit() else p for p in split("(\d+)",s)])
['a1', 'a2', 'a10', 'a14']
Comunque in Python per scopi reali uso la seguente funzione: ( Clicca qui ) | ||||||
| comments: Leave a comment |
July 29th, 2006
| ||||||||
| Python is too much slow for some of my purposes, so I've started to take a look at the Boo language. After seeing Python at a side, and C/C++/Delphi at the other, I didn't think of looking for other languages, but ShedSkin compiler has shown me that hi-speed execution and a very nice syntax are possible in the same language. Boo syntax is almost the same of Python, but it is statically typed (when possible it used type inferencing), and it runs on DotNet. It's possible quite faster than Python. In theory its syntax is a in improvement of Python syntax, but I think it often fails in this purpose. To install Boo I have had to install the portable version of DotNet, about 24 MB of installer (not the version of more than 100 MB). Maybe it can be interesting to have a Boo/static Python-like language that works on Java VM too (at the moment there is Jython, but it's dynamic like Python). (And it can be interesting to have a ShedSkin that compiles for D Digital Mars language instead for C++). This tells something interesting about Boo strong point: http://www.atug.com/andypatterns/boo.ht A citation from that page: >The solution is to have a static typed system by default, with lots of type inferencing (yes, Boo does this) so that you don't need to waste your time declare the type of every single little thing. Then when you get a touch of "Godel incompleteness" in the static type system of your application... just introduce a little duck typing to release the pressure. You may pay a slight performance penalty at these "duck moments", but since most of your app is blazing along at statically compiled speeds, it doesn't matter (furthermore, the places where you used duck typing may not be the time critical ones, anyway). Boo has perhaps solved the static vs. dynamic debate by allowing both paradigms, allowing the developer to use the strengths and avoiding the weaknesses of each paradigm.< At the moment I'm a total newbie of Boo, so the following notes are just first impressions. If you have something to say, corrections, explanations, I'll appreciate them. - I like more the lowercase attributes of Python. They are often shorter and simpler too, and easier to remember. APIs are important. I presume the autor of Boo has done this to keep the names of the usual methods of C# (like string methods). Because of such method names Boo lines of code are often a longer than Python ones, and this isn't positive. - I don't like the static attribute, or attributes by default protected, the syntax to specify a char type, and probably I don't like the unless statement. - The use of "as" to specify types isn't bad and I find it acceptable (especially when a type name is long), but maybe the Pascal use of : is shorter and can be understood anyway (but maybe this clashes with some other syntax, maybe dict elements syntax). - Books (at the moment?) lacks named variables in the function calls (they can be implemented, I think I know a couple ways to do it with C++ too). - Are duck (variant) objects *never* used by default, and used only when they are explicitly requested? Knowing this for sure makes me more relaxed if my purpose is to go faster than Python. (I have created a dict, and it looks duck-typed, because it accepts all kind of types, while C# Hashes seems typed. Can Boo dicts by statically typed?). - At the moment the error messages are bad, much worse than Python ones. I presume with time they will improve. - I think Python choice is the right one to avoid the x++ and --x syntax, and the assignment as expression, to avoid bugs and make the language a little simpler. - Slice assignment seems unsupported yet in Boo: c[:] = d[:] - Not possible in Boo, you have to use a (literal supported) RegExp, I haven't tested the relative speed of this Python string method and the equivalent Boo RegExp: "bab".split("a") - I sometimes use multiline strings are multiline comments (but it's not a very good practice). Boo has multiline comments (that I appreciate) but it doesn't accept a free-floating multiline string. - To convert a number n to string, you have to do str(n) with Python, and n.ToString() with Boo. The Python version is shorter and nicer, I don't care much of Ruby-like "OOP purity". But probably the version I'd like more is i.str even shorter, fast to type, and nicer to the eyes. - The Python type(x) seems better (shorter, simpler) than x.GetType() of Boo. A nice alternative can be just x.type - At the moment there aren't full docs for Boo, for example to have a list of string methods (like this nice page: http://docs.python.org/lib/string-metho - I hope with time Boo syntax will improve, and become nicer, like Python one. - I like some things in Boo too, like the optional self (but can't it produce some problems? I'll have to learn Boo more. Python developers keep refusing this change on the base of technical reasons, but they don't understand that lot of people just don't like to write self. every time, such people doesn't care if this change in the language gives problems. Maybe instead of "self." Python can use a different symbol, like ยง, or @, because using nothing may cause some problems), Main instead of if name == __main__ (if I have understood it well!), the syntax of super() looks nicer. - I think Boo: private x as int looks a bit better than the two underscores used in Python: __x - I'll have to learn how Boo dicts solves the mutability problem of lists that have to be used as dict keys (Boo doesn't have tuples, maybe lists can be frozen). - I don't know if I can produce true executables that can be run on a Win 95 withot dotnet installed (ShedSkin can do this). - I think Boo dicts don't have iter-something methods. - I think this Python 2.5 syntax isn't supported yet by Boo: x = 6 if i < 2 else 3 - An idea: x.copy and x.deepcopy for every object may be a good way to avoid the Python import copy - Some of the stuff explained in the "Structure of a Boo script" looks complex: http://boo.codehaus.org/Structure+o I have done few speed tests (on a PIII 500 MHz PC) with Python, Psyco, Boo and ShedSkin. I like the results of dict_speed, faster than Psyco and much faster than ShedSkin. But I don't understand why the array_performance is so much worse than Psyco (Psyco compiles too in that time!). The overall results aren't that good. But I have to do more tests. ============================================
array_performance.boo:
def test():
items = 2000000
a = array(object, range(items))
collect = []
for i in range(items):
collect.Add(a[i])
test()
-------------------
array_performance.py:
def test():
items = 2000000
a = range(items)
collect = []
for i in xrange(items):
collect.append(a[i])
return collect[0]
#import psyco; psyco.bind(test)
print test()
array_performance, items = 2000000:
Python: 5.53 s
Boo: 4.17 s
Psyco: 2.23 s
ShedSkin: 0.5 s
ShedSkin -DNOWRAP: 0.5 s
============================================
dict_speed.boo:
def main():
n = 100
k = 10000
d = {}
for i in range(n):
d["key" + i.ToString()] = i
aux = true
for i in range(k):
for j in range(n):
if "key" + i.ToString() in d:
aux = false
print d["key" + (n-1).ToString()], aux
main()
-------------------
dict_speed.py:
def main():
n = 100
k = 10000
d = {}
for i in xrange(n):
d["key" + str(i)] = i
aux = True
for i in xrange(k):
for j in xrange(n):
if ("key" + str(i)) in d:
aux = False
print d["key" + str(n-1)], aux
#import psyco; psyco.bind(main)
main()
dict_speed, present, n = 100, k = 10000:
ShedSkin: 19.22 s
Python: 7.17 s
Psyco: 4.90 s
Boo: 3.43 s
============================================
slice_copy1.boo:
def fun1(v1 as (int), v2 as (int), n):
l = len(v1)
for nn in range(n):
for i in range(l):
v1[i] = v2[i]
return v1[1]
m = 1000
n = 30000
v1 = array(int, range(m))
v2 = array(int, range(m))
print fun1(v1, v2, n)
-------------------
slice_copy1.py:
def fun1(v1, v2, n):
l = len(v1)
for nn in xrange(n):
for i in xrange(l):
v1[i] = v2[i]
return v1[1]
m = 1000
n = 30000
v1 = range(m)
v2 = list(v1)
import psyco; psyco.bind(fun1)
print fun1(v1, v2, n)
Timings slice_copy1, m=1000, n=30_000:
Python: 25.6 s
Boo: 8.08 s
Psyco: 1.78 s
ShedSkin -DNOWRAP: 0.28 s
m=1000, n=300_000, op=1:
Python:
Psyco:
ShedSkin -DNOWRAP: 1.94 s
============================================
split_append.boo:
def test():
n = 2 * 10**6
l1 = ["x " for i in range(n)]
s = l1.Join("")
l2 = s.Split()
print l2[0]
test()
-------------------
split_append.py:
def test():
n = 2 * 10**6
l1 = ["x " for i in xrange(n)]
s = "".join(l1)
l2 = s.split()
print l2[0]
import psyco; psyco.bind(test)
test()
split_append.py, n = 2 * 10**6 :
Boo with list: 10.6 s (~83 MB used)
Boo with array:
ShedSkin: 10.32 (~90 MB used)
Python: 5.23 s (~20 MB used)
Psyco: 3.43 s (~22 MB used)
============================================ | ||||||||
| comments: Leave a comment |
leonardo
|
|||||||||||||