Java > Scala

[Marco Leise]

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.
>
>
> --
> Paulo

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:
>>
>> https://raw.github.com/gist/1406238/72ade1a89004a9a7d705b00cfd14b90b2b6a26bd/gistfile1.txt
>>
>> 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  
>> faults, like PHP and JavaScript. So I don't know.
>>
>> ----------------
>>
>>  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  
>> enforcement).
>>
>> Bye,
>> bearophile