• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

Re: impara a programmare in 10 anni

On Wed, 8 Jul 2009 11:50:00 +0000 (UTC), "Luca Menegotto"
<otlucaCAVAMI@CAVAMIyahoo.it> wrote:

>riccardo wrote:
>
>> appunto. Qui non stiamo parlando di quale linguaggio sia piu'
>> difficile da imparare da cima a fondo ma di quale possa essere adatto
>> per imparare a programmare. Il C++ va benissimo.
>
>IMHO il C++ è troppo complesso come linguaggio didattico. Capiamoci, a
>me piaceva il C++, ho studiato sui libri del buon Bjarne e di Lippman.
>Pero' mi sono accorto che ci sono cose per le quali, forse, passare per
>qualcosa di meno complesso per apprendere i principi base forse è
>meglio.

Buongiorno, buonsenso. Finalmente :)

>> Stroustrup parla di due anni partendo da ZERO. E partendo da zero un
>> periodo di due anni e' il minimo che ci si possa aspettare per passare
>> da zero a programmatore.
>
>Vero. E' vero anche che due anni sono una quantità di tempo enorme.
>Caspita, se non ce la fai in due anni, cambia mestiere!

"Most experienced programmers I have talked with quotes times from a
half year to one and a half year for becomming really comfortable with
C++ and the key data abstraction and object- oriented techniques it
supports."

Non so a te, ma a me pare davvero molto rapportato ad altri strumenti,
quali che siano i numeri riportati (che sono sempre un fatto personale
alla fine).

Tu quanto ci hai messo per curiosità? E a che livello pensi di essere?
Dici di stare molto più su di uno Steve Yegge (Amazon,Google,etc... in
ruoli di una certa entità), che giudichi uno che non ha capito una
roboante mazza? Nel caso rispondessi di "si" all'ultima, (seriamente e
senza alcuna ironia) mi faresti da mentore?

Io pagherei per avere Yegge come mentore, altro che dargli
dell'incompetente, ma siamo diversi a quanto pare.

>> tutti i linguaggi hanno particolarita' e tutti vanno usati con cura e
>> attenzione.
>
>
>Aggiungerei: ogni compito ha il suo linguaggio di elezione. Ma, ahime,
>non si può conoscere tutto...
>
>> I grandi comunque non rifuggono affatto da un bel niente,
>> semplicemente mantengono una mente aperta e studiano il maggior numero
>> di strumenti possibile, in modo da poter utilizzare quello piu'
>> appropriato al tipo di problema che devono risolvere.
>
>Come non quotare?
>
>> Termino con questa citazione di Yegge:
>> "C++ is dumb, and you can't write smart systems in a dumb language.
>> Languages shape the world. Dumb languages make for dumb worlds."
>> Penso che riassuma tristemente il livello del personaggio ...
>
>Condivido. Chi scrive una cosa del genere non ha capito una mazza
>quadra. C++, per le complessità che hai esposto, non è un linguaggio
>applicabile ovunque. Ma è solido, ben supportato, ben implementato.
>Certo, ci puoi fare delle porcherie inenarrabili, che magari altre cose
>non ti consentono, pero' ti consente anche livelli prestazionali che
>gli altri si sognano. Come sempre, il programmatore è ciò che conta.

Ma cos'è per te un linguaggio *dumb*? Introspection, anyone?

Ti riporto un interessante post di Alex Martelli, da gente del suo
calibro si impara spesso finanche più che dagli inventori stessi degli
strumenti in questione. Sono sicuro lo troverai interessante.
(trovi qui http://snipurl.com/md4j9 il thread dell'epoca)


Steve Mullarkey <steve...@ozemail.com.au> wrote in message

news:8F4E9C028stevemulozemailcomau@139.130.250.4...

> I have been a 'C' programmer for the past 15 years and a "C++"
> programmer for the past 3 years. I'm not a genius but would modestly (?)
> class myself as reasonably competent.

> In the past week I have become aware of Python. I've bought a book and
> read this newsgroup every day.

> I have read in several places productivity claims of 5 to 10 times over
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.

I have not "moved" from C++ to Python: most of my professional
development (what I get paid for) is still C++.  For personal
programming projects, such as my bridge studies, I've moved most
stuff to Python (everything that used to be in Perl, and a good
fraction of what used to be in C or C++).

> In "C++" I have :-

> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..

My favourite editor has always been vi (now, and since a few years,
in the free gvim version), and it's just as good for Python as it is
for C++.  Otherwise, I find PythonWin and IDLE adequate substitutes
for Microsoft Visual Studio.  ObWarning: I don't do much GUI's, in
either language, so I have no experience of how the GUI builders
compare; Hammond and Robinson's "Python Programming on Win32" seems
to do an adequate job of presenting a huge variety of different
approaches you can use -- if I did have a huge investment in a GUI
builder I'm sure I could keep it (a GUI shell in VB, Delphi, or
whatever you prefer, with most or all of the real work in Python).

> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.

I suspect that here we see the usual confusion between STL (the
prototype experimental research thingy which provided inspiration
for what is now in the C++ standard and has since kept changing)
and the Standard C++ Library.  Matters only to pedants like me, I
guess, but one of the little things giving me joy is that I just
barely managed to catch this confusion about to be propagated in
Eckel's otherwise-excellent "Thinking in C++" 2nd edition, and it
was in time to have him correct it (he's such a wonderful writer,
I hope he really gets to grips with the "Thinking in Python" book
he mentions as a possibility!).

Anyway, back to your point 2: Python's dictionaries, lists, and
strings, give you basically all you get from Standard C++'s
containers, and then some.  You may have to do some adaptation
for certain constructs (e.g., remap a std::multimap<> in terms
of a dictionary with lists as entries), and some of the best
features of C++'s <algorithm> are missing (std::next_permutation,
for example), but I notice you don't mention those so I guess
you won't miss them (there is sure to be something around the
net usable as a substitute, anyway:-).

> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.

> 4. I can also use background compiling and linking.

> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..

No compiling and linking at all surely beats even those "very
small amounts", and the good stuff you can find on the net for
Python is a LOT.

> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated.

For many people, I suspect a key issue is that they never really
understood _100%_ of C++.  It IS a hugely complex language, and
an ENORMOUS investment is needed to fully grasp 90% of it; just
as much effort and expense, to move up to 99%; and as much again,
to get to 99.9%.  I'm about at this last level, so I'm RARELY bitten
by things I just didn't understand perfectly, but I'm unwilling
to do it all over again to get to 99.99% (particularly since, at
this level, existing implementations still deviate substantially
from the Standard).  But I also do consulting and mentoring, and
see presumably-experienced C++ programmers baffled by issues such
as
MyClass my(5);   // declares a variable
MyClass mx();    // declares a function, NOT a variable
or
std::copy(a.begin(), a.end(), b.begin());    // does NOT extend b!
etc, etc, as well as 'deeper' issues such as partial template
specialization, order-of-initialization issues, dominance rules,
the distinctions between overriding, overloading, and hiding, &c.

Judging from my experience, over 90% of "experienced C++ programmers"
have a 90%-or-less grasp of the C++ language.  This is quite
understandable given its complexity and difficulty, but surely
explains why such programmers would be much more productive in
a language that is simple enough that they CAN grasp it well with
much more modest effort (and, mostly, carefully designed so that
not-fully-grasped issues don't rear up and bite you when you
least expect it:-).

However, avoiding C++'s traps and pitfalls is not really where the
big gains came for me, since I'm reasonably well-versed in avoiding
them (and have the scars to prove it:-).  Rather, for me personally
the key issues have to do with Python's intrinsically-dynamic nature.

Exploratory programming, ease of reuse, very easy refactoring, are
three key issues.  In C++, you have to start with a substantially
"right" class structure; you can do minor tweaks, but you can't really
go very far "just playing around with various possibilities"; and when
you see a refactoring would be warranted, it's most often a lot of
work.  Plus, to get any substantial reuse value out of your work, you
have to invest a lot in making it _reusable_ in the first place, or
in reworking it with reusability in mind -- very worthwhile
investment,
but still hard to do under production deadlines.  Python's more fluid,
dynamic style helps on all of these fronts: you play around more, get
more possibilities explored, refactor more frequently and effectively,
and get reuse without huge up-front investments in reusability.

> I am genuinely interested
> to ask "C++" programmers :-

> 1. What productivity increase do you achieve ?

I've never measured it precisely, but it does lie somewhere
between a factor of 2 and one of 10.  It's probably less for
areas one knows so well (having written a dozen separate programs
or subsystems for them) that one could recode them in one's
sleep, while it tends to the higher end for areas where the
exploratory-programming and refactoring advantages loom large.

> 2. How long did you use Python before you achieved increased
> productivity ?

A couple of weeks (versus a decade of C++, and C before that).
One of the most amazing characteristics of Pythin is how
amazingly FAST one becomes productive with it.

Alex

Antworten