Java > Scala
Marco.Leise at gmx.de
Wed Nov 30 02:22:22 PST 2011
Am 30.11.2011, 08:21 Uhr, schrieb Paulo Pinto <pjmlp at progtools.org>:
> Quite an interesting read, but I cannot stop to think than again is one
> of the typical "blame the tool" thing.
> In my line of business we only allow employees with proper university
> background to enter the company, and even so, we get developers which I
> keep asking if they learned anything at all while at the university.
> Even for them Java is a very complex language. I already spent quite
> some hours explaining programming concepts that made me think if I was
> explaining programming to children. But then again, I don't have any
> control about the hiring process in these companies.
There are schools that teach programming from the practical point of view
as opposed to the theoretical university background. While you have to set
a higher bar in regards to the grades there, those people may know Java or
C# and tools better as well as being taught team work and presentations by
example projects. Since the school would be in close contact to actual
companies they know best, what a typical programmer needs to learn in 2-3
years to some work done in a company.
The trade-off is the lack of academical background. They may not have
heard much about the big-O notation and other CS terms or how algorithms
other than bubble-sort and quick-sort work.
But more often than not, an employer just wants someone they can give a
workspace with Eclipse or VisualStudio and let them do some small task on
an existing code base right away. (my experience)
I also had my time explaining objects to a trainee. But it was a relief
for me when she started to understand what a pointer is and how two of
them can refer to the same object.
> Am 30.11.2011 02:34, schrieb bearophile:
>> A recently written report from a firm that has switched back from Scala
>> to Java:
>> Some people say that programmers often show a religious-like attachment
>> to their preferred languages, but I suspect that often the truth is
>> just that new languages are not good enough for practical work. Even
>> languages like Scala that seem very carefully designed by geniuses, a
>> language that is also easily integrated with Java code, that is one of
>> the most successful and used languages of the world, risk to be a
>> failure for a good number of people. Designing a good enough new
>> language is hard, maybe 99% of the newly designed languages fail, and
>> creating a language that is also usable in daily work is much harder.
>> Regarding D2, I think in the last year it is coming out of a phase of
>> its development: I no longer find a new compiler bug every time I write
>> 20 lines of D2 code. It happens still, but it's now an uncommon thing.
>> I don't have a wide experience about designing new languages, so it's
>> not easy to give good suggestions. But now I suggest to keep some focus
>> about removing important/basic design bugs/faults of D, like the recent
>> removal of covariance -related array problem. Example: D2 foreach is
>> currently broken in two different ways. On the other hand there are
>> examples of successful languages that contain several basic design
>> From that text:
>>> 5. Avoid closures. [...] At some point, we stopped seeing lambdas as
>>> free and started seeing them as syntactic sugar on top of anonymous
>>> classes and thus acquired the same distaste for them as we did
>>> anonymous classes.<
>> D2 closures are probably better, they aren't syntactic sugar on top of
>> anonymous classes. On the other hand invisible sources of low
>> performance are a bad thing in a language as D2. This is why I have
>> suggested to add a compiler switch that lists all the closures of a
>> module (or other related ideas about no heap activity tests or
More information about the Digitalmars-d