Quale linguaggio studiare?

[cdtux]

L'utente ha richiesto informazioni inerenti ai requisiti tecnici di base richiesti dalla polizia postale, che notoriamente si occupa di reati perpetrati tramite reti & co. (Tipo frodi con carte di credito, monitoraggio di chat/social)

Continuo a non capire quale attinenza abbia la virtualizzazione (micro e non) con la richiesta dell'utente.
A lui interessa il livello applicativo (web server, database, servizi, ecc..) non quello che sta "sotto".

Poi in base ai compiti che gli saranno assegnati, approfondirà gli argomenti più opportuni.

 

[Dclaudio1990]

Amico mio, molti membri della polizia postale non sanno nemmeno cosa è un server , ti ripeto che per entrare non serve di certo essere ingegneri ma solo periti.
Io stavo solo consigliando uno studio completo visto che credo che piaccia questo mondo.
:ciaociao:

 

[Stefano Novelli]

Amico mio, molti membri della polizia postale non sanno nemmeno cosa è un server , ti ripeto che per entrare non serve di certo essere ingegneri ma solo periti.
Io stavo solo consigliando uno studio completo visto che credo che piaccia questo mondo.
:ciaociao:

Dipende eh, ne conosco di pp che gli fumano le palle :asd:
Tornando a noi credo che lo studio in tecnico industriale informatico possa essere un buon inizio, poi una volta entrati nel mondo ci si guarda attorno e si valutano tutte le possibili specializzazioni.
In ogni caso, io studierei prima per avere fondamentali nel settore informatico a prescindere dal lavoro che voglio fare, esistono anche agenzie di investigazione oltre che gli organi competenti, in più il settore di IT Security nel privato sta crescendo (non in Italia eh) quindi se ti interessa il ramo della sicurezza la strada da prendere è ovviamente quella informatica.
Googlati qualcosa tipo Informatica Forense o Criminologia Informatica, magari ti aiuta a capire meglio di cosa tratta ;)

 

[Captcha]

L'utente ha richiesto informazioni inerenti ai requisiti tecnici di base richiesti dalla polizia postale, che notoriamente si occupa di reati perpetrati tramite reti & co. (Tipo frodi con carte di credito, monitoraggio di chat/social)

Continuo a non capire quale attinenza abbia la virtualizzazione (micro e non) con la richiesta dell'utente.
A lui interessa il livello applicativo (web server, database, servizi, ecc..) non quello che sta "sotto".

Poi in base ai compiti che gli saranno assegnati, approfondirà gli argomenti più opportuni.

In realtà credo che il monitoraggio di carte di credito etc sia compito del GAT della finanza.
Che io sappia la Polizia postale si occupa solo di contrasto alla pedopornografia

 

[Stefano Novelli]

Che io sappia la Polizia postale si occupa solo di contrasto alla pedopornografia

Non è così, la Polizia Postale si occupa di controllare gli illeciti perpetrate per messo delle comunicazioni, tra cui ovviamente Internet.
Quindi si occupa di ingegneria sociale, cybercrimine, truffe, pedofilia, intrusioni informatiche, violazioni dei diritti d'autore, vigilanza su frequenze audio e video, frodi in home banking, riciclaggio, terrorismo. Insomma, qualunque violazione mediante comunicazione a mezzo informatico.

 

[Captcha]

Non è così, la Polizia Postale si occupa di controllare gli illeciti perpetrate per messo delle comunicazioni, tra cui ovviamente Internet.
Quindi si occupa di ingegneria sociale, cybercrimine, truffe, pedofilia, intrusioni informatiche, violazioni dei diritti d'autore, vigilanza su frequenze audio e video, frodi in home banking, riciclaggio, terrorismo. Insomma, qualunque violazione mediante comunicazione a mezzo informatico.

In effetti non avrebbe molto senso quello che dicevo io.. Sono andato ad informarmi meglio.
Giustamente Carabinieri, Guardia di Finanza e Polizia di Stato, attraverso i loro reparti per la sicurezza informatica, svolgono tutti e 3 attività di controllo su illeciti per mezzo delle comunicazioni. Quindi non c'è una vera e propria "divisone dei compiti" (e ci mancherebbe, altrimenti se ogni forza dell'ordine fosse specializzata in qualcosa di particolare ci sarebbero ovvi problemi...)

 

[ocean62]

Per la programmazione se conosci bene il linguaggio C non avrai sicuramente problemi ad imparare altri linguaggi di alto livello.

Non sono d'accordo. Se conosci solo il C ti perdi tutta la parte OOP e di programmazione generica. Meglio iniziare subito con linguaggi che prevedono almeno l'OOP.

 

[cdtux]

È più difficile imparare la parte oop o la programmazione di basso livello (nel senso di gestione della memoria, ecc..)??

Secondo me è indubbiamente più complessa la seconda..
Per questo se hai delle buone basi con il c (e quindi di basso livello), è più semplice "integrare" la programmazione a oggetti (imho).

 

[Stefano Novelli]

È più difficile imparare la parte oop o la programmazione di basso livello (nel senso di gestione della memoria, ecc..)??

Secondo me è indubbiamente più complessa la seconda..
Per questo se hai delle buone basi con il c (e quindi di basso livello), è più semplice "integrare" la programmazione a oggetti (imho).

Sono due cose diverse, la oop è un paradigma di programmazione, la seconda è un tipo di linguaggio.
Sebbene non sia una pratica assai seguita, è possibile fare OOP su linguaggi low level come ASM (Object-Oriented Programming in Assembly Language | Dr Dobb's)

In più un linguaggio come C (cito il commento sopra) è un linguaggio imperativo ma facilmente "switchabile" a OOP (con il C++).
Diciamo che in base al linguaggio il manuale tende a insegnare il paradigma più appropriato (solitamente in base alla natività del linguaggio), se il linguaggio è fortemente OOP difficilmente lo si studierà come imperativo (vedi Ruby), in quanto poi tutto ciò che ne concerne (Framework e librerie in primis) saranno programmate con il paradigma OOP.

Se uno parte con Pascal o Fortran troverà difficile la programmazione OOP, su questo non c'è alcun dubbio, ma non significa che l'OOP sia difficile. Io personalmente provenendo da linguaggi imperativi come PHP 4 ho avuto difficoltà a passare a OOP con il 5, appunto perchè non ero abituato. Ho trovato più semplice l'uso di un linguaggio funzionale (altro paradigma usato per la programmazione in multithreading come Erlang => Elixir) ma rimane solo un paradigma, niente di più.

La programmazione a basso livello invece è il modo in cui puoi interagire con il computer che runna il software: un linguaggio ASM sarà più difficile da scrivere rispetto a un linguaggio di alto livello come Perl o Javascript perchè non ha una natura di programmazione dei controller di memoria, puntatori, vettori e via dicendo, quindi non c'è la necessità di conoscere architetture di processori nè di riallocare memorie e via dicendo.

La complessità di un linguaggio non è sempre direttamente proporzionale al paradigma che si usa: spesso si fa questa confusione (ed è giusto che sia così) quando si fa il passaggio da linguaggio ad alto livello (spesso interpretato) a linguaggio di basso livello (compilato) a cui si devono dare maggiori attenzioni specie in argomenti mai affrontati come appunto la memoria e le allocazioni in esse, soprattutto perchè in un linguaggio ad alto livello non si potrà mai gestire la memoria (che invece viene gestita in automatico dall'interprete).

IMHO se dovessi ricominciare a programmare partirei con Elixir, il giusto compromesso di linguaggio di programmazione che permette di sviluppare un software funzionante in meno di 2 settimane con un'ottima gestione del multithreading (e quindi un pieno supporto alle tecnologie multicore) senza lo sbatti di dover usare librerie esterne e funzioni ridondanti per riallocare processi e via dicendo. Se poi si vuole solo "giocare" con la programmazione qualunque linguaggio interpretato ad alto livello va bene, dipende solo dall'uso che se ne vuole fare. Tutto a prescindere dal paradigma, imperativo - OOP - funzionale che sia.

 

[cdtux]

Spezzo il quote così da rendere il tutto più leggibile.

Sono due cose diverse, la oop è un paradigma di programmazione, la seconda è un tipo di linguaggio.
Sebbene non sia una pratica assai seguita, è possibile fare OOP su linguaggi low level come ASM (Object-Oriented Programming in Assembly Language | Dr Dobb's)

In più un linguaggio come C (cito il commento sopra) è un linguaggio imperativo ma facilmente "switchabile" a OOP (con il C++).
Diciamo che in base al linguaggio il manuale tende a insegnare il paradigma più appropriato (solitamente in base alla natività del linguaggio), se il linguaggio è fortemente OOP difficilmente lo si studierà come imperativo (vedi Ruby), in quanto poi tutto ciò che ne concerne (Framework e librerie in primis) saranno programmate con il paradigma OOP.

Quello che hai scritto non è contestabile.. condivido in toto.

Se uno parte con Pascal o Fortran troverà difficile la programmazione OOP, su questo non c'è alcun dubbio, ma non significa che l'OOP sia difficile. Io personalmente provenendo da linguaggi imperativi come PHP 4 ho avuto difficoltà a passare a OOP con il 5, appunto perchè non ero abituato. Ho trovato più semplice l'uso di un linguaggio funzionale (altro paradigma usato per la programmazione in multithreading come Erlang => Elixir) ma rimane solo un paradigma, niente di più.

Per questo non posso concordare. Per quanto mi riguarda è stato incredibilmente più semplice passare da PHP4 a PHP5 (quindi imparare i paradigmi OOP), che studiare la programmazione di basso livello classica del C (del quale devo ammettere di non aver mai completato lo studio, principalmente per una questione di tempo).
Quando avrò completato lo studio del C, forse mi ricrederò.

La complessità di un linguaggio non è sempre direttamente proporzionale al paradigma che si usa: spesso si fa questa confusione (ed è giusto che sia così) quando si fa il passaggio da linguaggio ad alto livello (spesso interpretato) a linguaggio di basso livello (compilato) a cui si devono dare maggiori attenzioni specie in argomenti mai affrontati come appunto la memoria e le allocazioni in esse, soprattutto perchè in un linguaggio ad alto livello non si potrà mai gestire la memoria (che invece viene gestita in automatico dall'interprete).

IMHO se dovessi ricominciare a programmare partirei con Elixir, il giusto compromesso di linguaggio di programmazione che permette di sviluppare un software funzionante in meno di 2 settimane con un'ottima gestione del multithreading (e quindi un pieno supporto alle tecnologie multicore) senza lo sbatti di dover usare librerie esterne e funzioni ridondanti per riallocare processi e via dicendo. Se poi si vuole solo "giocare" con la programmazione qualunque linguaggio interpretato ad alto livello va bene, dipende solo dall'uso che se ne vuole fare. Tutto a prescindere dal paradigma, imperativo - OOP - funzionale che sia.

Concordo con quanto evidenziato in grassetto.

 

[Stefano Novelli]

Per questo non posso concordare. Per quanto mi riguarda è stato incredibilmente più semplice passare da PHP4 a PHP5 (quindi imparare i paradigmi OOP), che studiare la programmazione di basso livello classica del C (del quale devo ammettere di non aver mai completato lo studio, principalmente per una questione di tempo).
Quando avrò completato lo studio del C, forse mi ricrederò.

Ma infatti è tutto soggettivo, il passaggio da PHP 4 a 5 ha reso semplice il passaggio a OOP anche perchè altrimenti nessuno avrebbe più programmato in PHP. Succederà la stessa cosa con PHP 7 quando si inizierà a parlare di multithreading e saranno necessarie nuove implementazioni al paradigma ma vedrai che sarà meno complicato.
Il punto è che se passi con linguaggio X da imperativo a OOP è sicuramente più semplice che passare da linguaggio X a Y (specie se parliamo di C che è un linguaggio se vogliamo di "medio" livello confrontato con un linguaggio di alto/altissimo livello come PHP), semplicemente perchè ne conosci già sintassi e semantica.
Ma questo si riduce solo al caso in cui tu conosca già un linguaggio di alto livello, se presi da uno che non ci capisce niente di programmazione paradigmi e linguaggi sono due cose diverse con due pesi e due misure.

Ti faccio un esempio banale, anzi banalissimo:
Elixir, paradigma funzionale. Non esistono classi (per modo di dire) e tutto gira intorno al multithreading. Ma non è tutto: non ci sono conditional statements come if (cioè, ci sono, ma non come li interpreti tu), le variabili non si possono riassegnare (se x = 0 non potrà mai più essere x=1) e non esistono i cicli for e while.
E allora uno come me ha trovato più difficoltà a imparare il paradigma funzionale anzichè la creazione dei processi, perchè in questo caso il paradigma funzionale risulta più complesso da digerire rispetto ai bytecode (che in qualche modo fanno riferimento alle memorie).

Ed ecco come un paradigma è più complesso di un altro "livello" di linguaggio: la difficoltà di un apprendimento è relativo a come lo si studia o a come abbiamo studiato la programmazione in passato. Se poi ci si mettono le astrazioni del linguaggio che lo differenziano (vedi un esempio con golang e le stramaledette interfacce) tutto diventa più difficile ma lì cambia l'ottica del linguaggio, la OOP nel bene o nel male è identica per tutti i linguaggi.

 

[cdtux]

Partendo dal presupposto che una persona conosca già un linguaggio di programmazione, il "se passi con linguaggio X da imperativo a OOP è sicuramente più semplice che passare da linguaggio X a Y" è sicuramente vera ma trascurabile in alcuni casi.

Il paradigma di programmazione OOP è (IMHO) molto più "affine" al paradigma procedurale rispetto ad altri (non vorrei dire una cavolata, ma mi pare che come "concetto" sia nato proprio all'interno di questo paradigma), quindi in questo caso passare da "X a Y", come ad esempio da C (procedurale) a python (oggetti) può risultare molto semplice.
Se poi andiamo a guardare la sintassi, possiamo certamente constatare che è molto simile (ad esempio la sintassi di un if in C, PHP, Ruby o Python, è praticamente uguale per tutti) tra i vari linguaggi. La sintassi è comunque solo questione di abitudine.
Passare invece da python a C (ad esempio) lo vedo invece un po più complicato.

In caso di passaggio di altri paradigmi completamente differenti, invece, concordo con te.
Passare da "X a Y" può essere davvero complicato (come nel caso di Elixir).
La parte dichiarativa delle query SQL può essere un altro esempio.

Il tutto è comunque piuttosto soggettivo.

 

[Stefano Novelli]

Partendo dal presupposto che una persona conosca già un linguaggio di programmazione, il "se passi con linguaggio X da imperativo a OOP è sicuramente più semplice che passare da linguaggio X a Y" è sicuramente vera ma trascurabile in alcuni casi.

Il paradigma di programmazione OOP è (IMHO) molto più "affine" al paradigma procedurale rispetto ad altri (non vorrei dire una cavolata, ma mi pare che come "concetto" sia nato proprio all'interno di questo paradigma), quindi in questo caso passare da "X a Y", come ad esempio da C (procedurale) a python (oggetti) può risultare molto semplice.
Se poi andiamo a guardare la sintassi, possiamo certamente constatare che è molto simile (ad esempio la sintassi di un if in C, PHP, Ruby o Python, è praticamente uguale per tutti) tra i vari linguaggi. La sintassi è comunque solo questione di abitudine.
Passare invece da python a C (ad esempio) lo vedo invece un po più complicato.

In caso di passaggio di altri paradigmi completamente differenti, invece, concordo con te.
Passare da "X a Y" può essere davvero complicato (come nel caso di Elixir).
La parte dichiarativa delle query SQL può essere un altro esempio.

Il tutto è comunque piuttosto soggettivo.

D'accordo su tutto ;)