Pagina 8 di 10 primaprima ... 6 7 8 9 10 ultimoultimo
Visualizzazione dei risultati da 71 a 80 su 98
  1. #71
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,590
    Parzialmente correlato, articolo vecchio ma interessante.
    http://www.red-lang.org/2016/07/nati...7-loc.html?m=0
    Red e in generale i linguaggi REBOL like mi stupiscono sempre
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  2. #72
    Quote Originariamente inviata da Scara95 Visualizza il messaggio
    Common Lisp e Scheme sono guidati da standard, non da implementazioni...
    Sì, intendevo implementazione in senso lato... se vuoi nel senso di "istanziazione concreta" della più generale classe dei linguaggi di derivazione Lisp.
    Per i principi sono d'accordo anch'io, la mia domanda è perché uno dovrebbe scegliere razionalmente CL e non altre alternative?
    Ha buone capacità di metaprogrammazione e in questo siamo d'accordo tutti, ma la sintassi è quella che è e soprattutto CL (nello specifico) è secondo me molto prolisso. E le parentesi non aiutano quando devi scrivere tanto.
    È uno standard, c'è tanta roba (librerie) già scritta, ci sono implementazioni robuste e relativo tooling e che non spariranno dall'oggi al domani, c'è tanta documentazione in proposito, se cerco qualcuno che lavori ad un progetto in CL è probabile che lo trovi (al netto del fatto che già trovare un lisper rispetto ad un programmatore Java è cosa complicata).

    Tutti questi "corollari" ad un linguaggio quando poi ti trovi nel "mondo vero" e devi scriverci progetti veri (con magari un orizzonte temporale di una decina d'anni) sono importanti; ti faccio qualche esempio sparso di cose dove la "sexyness" del progetto non c'entra niente con la viabilità effettiva di utilizzo "nel mondo vero":
    • nim; linguaggio di sicuro interesse e con un sacco di idee interessanti; un mio collega ha provato a scriverci qualcosa per divertimento, ha passato i successivi tre giorni a discutere e a riportare bug all'autore del compilatore; in ogni caso, è un one-man project; magari diventa il prossimo Lua (progetto con una community ricca), magari diventa Haxe (prodotto solido ma ancora oggi one-man-project, se l'autore viene investito da un tram domani chi lo sostituisce?), magari lui si stufa e nim sparisce nel nulla;
    • GTK+; la documentazione è oscena e la gestione del progetto (specie da GTK3 in poi) è pessima: il ramo GTK2 è abbandonato, per passare a GTK3 di fatto è necessario un rewrite; ha convinto addirittura Linus Torvalds a scappare da C + GTK a C++ + Qt; se avessi un progetto scritto in GTK2, oltre ad aver bestemmiato fino a ieri per farlo andare, ora sarei nella cacca (vedi GIMP, che parla di passare a GTK3 da anni ma non ha le risorse per farlo);
    • winelib, sulla carta l'idea era interessante per migrare in maniera graduale una nostra applicazione Win32 a roba multipiattaforma, e intanto eseguirla nativamente su Linux; la cosa è fallita miseramente nel momento in cui si è visto che era sufficientemente poco usata/mantenuta da avere cose come le wstring che non funzionavano - e per non funzionavano intendo segfault (la causa era: il lato C++ compilato con winegcc ha impostazioni "alla Windows" con wchar_t di 2 byte, ma invoca il runtime C Linux già compilato con wchar_t da 4 byte, con risultati catastrofici); in generale, nel momento in cui l'unica documentazione disponibile è greppare i sorgenti la situazione non è rosea;
    • non mi ricordo quale framework figo del giorno con cui è stata sviluppata una web application interna, ora è morto e sepolto (o si è evoluto a tal punto da essere un prodotto completamente diverso e incompatibile); l'applicazione è bloccata con il framework nello stato in cui era quando è stata scritta, lo sviluppatore che l'aveva scritta è altrove, la cui documentazione del framework è ovviamente perduta come lacrime nella pioggia; ogni volta che ci si mette mano è grep nei sorgenti del toolkit;
    • SilverLight? WPF? Visual FoxPro? Visual J++? Quanti milioni di ore-uomo sono stati investiti in toolkit e linguaggi "sexy" sul momento ma che sono stati abbandonati dopo pochi anni perché non tiravano abbastanza? La cosa purtroppo vale anche per i progetti open - anche se almeno riesci a recuperare i sorgenti e a metterci le pezze;
    • addirittura MinGW - progetto ultrafamoso, per cui si immaginerebbe che la "quality of implementation" sia alta - se vai a guardarci dentro ci sono cose molto discutibili - winpthreads è un colabrodo di bug, abbiamo perso 12 giorni-uomo (i miei in particolari immerso nel disassembly) a capire che un nostro problema derivava da una race condition nel loro codice (con cose assurde per cui lanciando tre thread con tre argomenti diversi magari ne lanciava due con lo stesso argomento, e uno con NULL).


    Questo per dire: uscire dal mainstream è interessante e valido per un sacco di motivi, ma l'implementazione rodata, documentata, con un ampio supporto di mercato e con un ecosistema solido alle spalle spesso ha il suo "fascino noioso".
    Ultima modifica di MItaly; 03-10-2017 a 22:50
    Amaro C++, il gusto pieno dell'undefined behavior.

  3. #73
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,590
    Java viene insegnato in qualsiasi scuola/corso/università in cui si tratti di programmazione e viene presentato come la manna dal cielo per ogni problema che (se consideriamo il parco di librerie disponibili) non è neanche falsissimo, ma non lo definirei tale.
    Questo per dire che oltre a essere il linguaggio di fatto più diffuso è anche ben sostenuto dall'istruzione.

    Da un punto di vista lavorativo sono completamente d'accordo sul restare nel mainstream, di fatto che possano permettersi di sperimentare con grandi cambiamenti e tecnologie innovative sono solo "i big". Sono d'accordo anche per quando riguarda il ricco ecosistema CL e le ottime (e testate) implementazioni sia commerciali che gratuite. Però è come dire un suo mondo, isolato e in un certo senso marginale. Con parecchi pregi ma parecchi difetti. Per questo mi stavo chiedendo cosa potrebbe effettivamente portare a scegliere CL oggi...

    nim ho provato a scriverci un progettino per tipo 1 settimana, dopo l'n bug sul type system ho rinunciato...

    (REBOL era un linguaggio commerciale fino a n anni fa)
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  4. #74
    Quote Originariamente inviata da Scara95 Visualizza il messaggio
    Java viene insegnato in qualsiasi scuola/corso/università in cui si tratti di programmazione e viene presentato come la manna dal cielo per ogni problema che (se consideriamo il parco di librerie disponibili) non è neanche falsissimo, ma non lo definirei tale.
    Assolutamente, difatti bisogna trovare una via di mezzo, e ogni tanto magari correre rischi anche in produzione.
    Da un punto di vista lavorativo sono completamente d'accordo sul restare nel mainstream, di fatto che possano permettersi di sperimentare con grandi cambiamenti e tecnologie innovative sono solo "i big". Sono d'accordo anche per quando riguarda il ricco ecosistema CL e le ottime (e testate) implementazioni sia commerciali che gratuite. Però è come dire un suo mondo, isolato e in un certo senso marginale. Con parecchi pregi ma parecchi difetti. Per questo mi stavo chiedendo cosa potrebbe effettivamente portare a scegliere CL oggi...
    Non saprei, forse non è un caso se non conosco nessuno che usi CL "per davvero". Viceversa, ho sentito diversi "evangelisti" di Clojure (tra cui l'ottimo Eli Benderesky) - complice anche il fatto di avere a disposizione l'interop con l'ecosistema Java può essere una buona idea per progetti seri...
    nim ho provato a scriverci un progettino per tipo 1 settimana, dopo l'n bug sul type system ho rinunciato...
    A me ha iniziato a mettere paura quando ho visto la storia dei parametri che diceva essere passati "come se fossero copie" ma che per ragioni di efficienza di fatto passava "per const reference" nel caso delle stringhe, con risultati disastrosi in caso di aliasing tra un parametro var e uno let. Cercando nel manuale non trovo più la frase precisa, qualcuno deve avergli fatto notare la cosa.

    Sul resto, ricordo che continuava a rompersi soprattutto il compilatore verso JavaScript - o meglio, generava codice semanticamente rotto rispetto alle specifiche del linguaggio.
    (REBOL era un linguaggio commerciale fino a n anni fa)
    Indagherò

    ---

    Invece: partendo dall'assunto che per qualche motivo tutti i build system fanno schifo, per un progettino "esplorativo" al lavoro ho deciso di provare qbs e... funziona sorprendentemente bene, sono colpito! Ci sono dietro delle idee interessanti, e soprattutto mi sta facendo conoscere il mondo QML che finora avevo ingiustamente snobbato. Ha un po' di regole strane molto "praticone", e lo scripting è JavaScript (pro: potente, semantica nota; contro: per quanto nota, la semantica spesso è orrenda), ma devo dire che l'hanno pensata piuttosto bene - alla fine è un modo compatto e dichiarativo per dichiarare alberi di oggetti (che è quello che si fa di continuo in GUI e sistemi di build) e prototipi di alberi di oggetti, il tutto arricchito appunto dallo scripting imperativo. Vale la pena di provare a farci qualcosa.
    Amaro C++, il gusto pieno dell'undefined behavior.

  5. #75
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    • SilverLight? WPF? Visual FoxPro? Visual J++? Quanti milioni di ore-uomo sono stati investiti in toolkit e linguaggi "sexy" sul momento ma che sono stati abbandonati dopo pochi anni perché non tiravano abbastanza? La cosa purtroppo vale anche per i progetti open - anche se almeno riesci a recuperare i sorgenti e a metterci le pezze;
    un OT dentro un OT.

    WPF verrà abbandonato / non più supportato?
    e al posto suo che si dovrebbe usare??

    è più una semplice curiosità, perchè C# nnon lo uso granchè in verità.

  6. #76
    Mm diciamo che non gode di salute eccelsa; se guardi la history dei rilasci dal 2015 non ci sono rilasci nuovi (l'articolo è del 2015, ma non ho trovato nulla di più recente neanche nella documentazione Microsoft), e in ogni caso è dal 2013 che non ci sono feature significative. Viceversa, Microsoft stava in prima battuta puntando tanto sulle applicazioni "modern" (o "metro" o come si chiamano), e in ogni caso il mondo - per il bene e per il male - si sta spostando sul web (inteso come HTML5 e affini) - e non a caso Microsoft sta investendo in Azure. Non sembrano quindi intenzionati ad investire più energie su un framework per applicazioni rich client sciccoso ma tradizionale come impostazione.
    Amaro C++, il gusto pieno dell'undefined behavior.

  7. #77
    ottimo, grazie per la risposta.

    ma invece qualcuno ha testato haxe??
    dal sito sembra interessante.

  8. #78
    Quote Originariamente inviata da fermat Visualizza il messaggio
    ottimo, grazie per la risposta.

    ma invece qualcuno ha testato haxe??
    dal sito sembra interessante.
    L'aveva usato un mio collega una vita fa, non si era trovato male; ai tempi aveva un buon backend Flash, ora ha come target anche HTML5 e cose più nuove, può essere interessante.
    Amaro C++, il gusto pieno dell'undefined behavior.

  9. #79
    Unrelated: nuova macchina di build.

    (l'IP è ovviamente il .11 )
    Amaro C++, il gusto pieno dell'undefined behavior.

  10. #80
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    L'aveva usato un mio collega una vita fa, non si era trovato male; ai tempi aveva un buon backend Flash, ora ha come target anche HTML5 e cose più nuove, può essere interessante.
    perfetto grazie.
    se trovo il tempo di testarlo, vi dirò la mia!!

    Quote Originariamente inviata da MItaly Visualizza il messaggio
    Unrelated: nuova macchina di build.
    scusa l'ignoranza, ma per macchina di build che intendi di preciso??
    giusto per curiosità!

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.