traduzione terminologia

[Luca Delucchi]

Ciao a tutti, volevo capire come tradurre (e se necessario) i seguenti termini
- service shared object
   si rifà a questa frase A cgi-env directory which will contain all
the zcfg metadata files and the service shared object (C Shared
Library or Python module)

- datatype (riguardante il linguaggio C) per esempio quello qui sotto:

  typedef struct maps{
                char* name;
  struct map* content;
  struct maps* next;
 } maps;

grazie
Luca
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[a.furieri]

On Tue, 9 Nov 2010 16:39:29 +0100, Luca Delucchi wrote
> Ciao a tutti, volevo capire come tradurre (e se necessario) i
> seguenti termini - service shared object   si rifà a questa frase A
> cgi-env directory which will contain all the zcfg metadata files and
> the service shared object (C Shared Library or Python module)
>

??? service shared object ????
sia l'una che l'altra cosa sono essenzialmente
delle banali librerie a caricamento dinamico.
nel caso dei moduli Python accompagnate da
qualche meta-file (egg).

non divertiamoci ad inventare termini
nuovi ad ogni passo per definire roba
nota e stranota sotto altri nomi più
comuni.
 

> - datatype (riguardante il linguaggio C) per esempio quello qui sotto:
>
>   typedef struct maps{
> char* name;
>   struct map* content;
>   struct maps* next;
>  } maps;
>

datatype = tipo di dati

non riguarda solo il C, ma qualsiasi linguaggio
basato appunto sulla tipizzazione
(praticamente tutti, escludendo i "trottolini"
come JavaScript, Python, VisualBasic ...)

ma personalmente eviteri di tradurre, perchè
è uno di quei casi in cui il termine inglese
ormai è diventato di uso corrente (almeno
tra gli addetti)

ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[Paolo Corti]

> non riguarda solo il C, ma qualsiasi linguaggio
> basato appunto sulla tipizzazione
> (praticamente tutti, escludendo i "trottolini"
> come JavaScript, Python, VisualBasic ...)

dando del trottolino a Python (e in qualche modo anche a JavaScript)
secondo me ti stai facendo piu' di qualche nemico! :D
per VisualBasic la definizione calza :P

--
Paolo Corti
GIS specialist and web developer
web: http://www.paolocorti.net
twitter: @paolo_corti
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[a.furieri]

On Tue, 9 Nov 2010 17:30:31 +0100, Paolo Corti wrote
> dando del trottolino a Python (e in qualche modo anche a JavaScript)
> secondo me ti stai facendo piu' di qualche nemico! :D
> per VisualBasic la definizione calza :P
>

ok, chiedo parzialmente venia per Python:
nonostante sia typeless è abbastanza rigoroso
e consistente da risultare ragionevolmente
usabile.

ma JS è un dannato casino :P
meno male che poi qualche anima pia
ha provveduto ad inventare FireBug

ma tu Paolo te lo ricordi che incubo
era fare debugging JS qualche anno fa ?
... magari sul 'mitico' MSIE 5.5 ...

comunque su un punto sicuramente concordiamo:
è veramente molto difficile (se non assolutamente
impossibile) riuscire a trovare un casino senza
capo ne coda più pasticciato di VB :-)

ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[Luca Delucchi]

Il 09 novembre 2010 17:01,  <[hidden email]> ha scritto:

> On Tue, 9 Nov 2010 16:39:29 +0100, Luca Delucchi wrote
>> Ciao a tutti, volevo capire come tradurre (e se necessario) i
>> seguenti termini - service shared object   si rifà a questa frase A
>> cgi-env directory which will contain all the zcfg metadata files and
>> the service shared object (C Shared Library or Python module)
>>
>
> ??? service shared object ????
> sia l'una che l'altra cosa sono essenzialmente
> delle banali librerie a caricamento dinamico.
> nel caso dei moduli Python accompagnate da
> qualche meta-file (egg).
>

ok...

> non divertiamoci ad inventare termini
> nuovi ad ogni passo per definire roba
> nota e stranota sotto altri nomi più
> comuni.
>

non ho capito bene a cosa ti riferisci, io l'ho solo trovata non me la
sono inventata io :-P

>
> datatype = tipo di dati
>

immaginavo però volevo esserne sicuro

>
> ciao Sandro
>

ciao
Luca
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[Paolo Corti]

Ciao Sandro

> ma JS č un dannato casino :P
> meno male che poi qualche anima pia
> ha provveduto ad inventare FireBug

che fosse problematica l'implementazione, sono d'accordo e sicuramente
FireBug ha dato una grande mano.
Ma il linguaggio di per se e' molto potente ed ha una sua grande dignita', IMHO.
Ne e' dimostrazione il proliferare delle librerie, talvolta molto
eleganti, che astraggono con un layer intermedio la complessita' allo
sviluppatore (ad es jQuery o Ext JS).

Quello che a volte, a causa di implementazioni veloci e farraginose e
- non ultima - magari la scarsa conoscenza dello stesso da parte dello
sviluppatore, puo' sembrare un linguaggio brutto e scomodo, puo'
prendere nuova luce se visto in ottiche diverse, quali ad es le
elegantissime implementazioni di OpenLayers o di jQuery, tanto per
fare due esempi noti ai piu'.

Ed ora sta di nuovo succedendo qualcosa di nuovo: dopo il rilascio di
V8 [1] da parte di Google, c'e' ad es questo node.js [2] che sembra
abbia performance impensabili e una scalabilita' grandiosa e che mette
a disposizione possibilita' di chiamate asincrone in maniera molto
semplice. Tanto e' vero che stanno nascendo framework server basati su
tale implementazione, quali ad es Express [3], che tra l'altro si
accoppiano benissimo con i nuovi storage NoSQL (ad es CouchDb o
MondoDb, tanto per dirne due tra i piu' noti).
Insomma lunga vita al JavaScript, anche se sovente puo' evocare brutti
ricordi :D

> ma tu Paolo te lo ricordi che incubo
> era fare debugging JS qualche anno fa ?
> ... magari sul 'mitico' MSIE 5.5 ...

praticamente una pletora di alert et similia :D
infatti FireBug ha secondo me il merito principale per l'uscita dei
framework javascript di cui ho scritto in precedenza.
V8 dara' ora ulteriore spinta.

> comunque su un punto sicuramente concordiamo:
> č veramente molto difficile (se non assolutamente
> impossibile) riuscire a trovare un casino senza
> capo ne coda piů pasticciato di VB :-)
>

infatti (e lo dico da persona che ha usato VB5/6 per anni) e' un
linguaggio/strumento diseducativo che dovrebbe essere proibito a chi
si avvicina alla programmazione :P
E per di piu', ora che non ha quasi piu' senso sviluppare applicazioni
gestionali desktop, e' anche diventato privo di utilita', secondo me.

ci vediamo a Foligno, un caro saluto
P

[1] http://code.google.com/p/v8/
[2] http://nodejs.org
[3] http://expressjs.com

--
Paolo Corti
GIS specialist and web developer
web: http://www.paolocorti.net
twitter: @paolo_corti
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[a.furieri]

On Wed, 10 Nov 2010 09:21:27 +0100, Luca Delucchi wrote

> > ??? service shared object ????
> > sia l'una che l'altra cosa sono essenzialmente
> > delle banali librerie a caricamento dinamico.
> > nel caso dei moduli Python accompagnate da
> > qualche meta-file (egg).
> >
>
> ok...
>
> > non divertiamoci ad inventare termini
> > nuovi ad ogni passo per definire roba
> > nota e stranota sotto altri nomi più
> > comuni.
> >
>
> non ho capito bene a cosa ti riferisci, io l'ho solo trovata non me
> la sono inventata io :-P
>

Luca, lo so bene che non te la sei inventata tu ...
giusto per capirci fino in fondo e per avere
un quadro più organico e completo:

- nella notte dei tempi esisteva solo lo static
  linkage: cioè il software era già organizzato in moduli
  distinti (librerie), ma era obbligatorio "cucire"
  (link) tutti i moduli necessari dentro all'eseguibile
  al momento della build: dopo di che non era più possibile
  nessuna modifica (appunto: statico)

- in tempi successivi (anni '80) è stato introdotto
  il dynamic linkage: ora i moduli sono completamente
  esterni all'eseguibile, e verranno collegati solo
  al momento dell'esecuzione (run time).
  insomma, le benedette DLL aka shared libraries

- una ulteriore evoluzione di questa architettura
  dinamica consente addirittura di collegare in run
  time anche moduli niente affatto previsti in fase di
  progettazione iniziale (a patto che questi moduli
  implementino un'interfaccia standard e ben nota).
  ed ecco che nascono così le architture "a plugin".

in fondo Python (come tantissimi altri SW) lavora
semplicemente così quando richiami una IMPORT FROM:
va a cercarsi in una directory nota un EGG-file
di configurazione per quel package, dopo di che
si carica la DLL aka shared library relativa.

quindi possiamo divertici a chiamarli in mille
modi: moduli, estensioni, espansioni, plug-in ...

ma in fondo al meccanismo ci trovi sempre e
comunque le librerie a caricamento dinamico

ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010