On 2013-11-05 00:03, Nick Sabalausky wrote:

> Yea. In college, I was a CS tutor for the first year programming
> students. This was at a school that used Java. I can personally vouch
> that Java's a terrible language for beginners. (Well, and for everyone
> else, really ;) )
>
> A major part of the problem is Java's religious fervor for OO. There's a
> natural tendency for the students to end up being taught OO *before*
> they have a sufficient grasp on flow-of-execution (In fact, Java makes
> it difficult for the teachers to avoid doing that.) But, OO is an
> *architectural* concept that's completely meaningless (and in my
> observations, extremely confusing) without some form of either
> imperative or declarative foundation.
>
> The other issue is Java's insane amount of boilerplate. Great way to
> teach beginners that programming is tedious.

We had to learn Object Oriented Analysis and Design before any programming in Java at the university.

-- 
/Jacob Carlborg

On Tuesday, 5 November 2013 at 06:21:34 UTC, H. S. Teoh wrote:
> On Mon, Nov 04, 2013 at 06:12:33PM +0100, PauloPinto wrote:
>> On Monday, 4 November 2013 at 16:49:10 UTC, simendsjo wrote:
>> >On Monday, 4 November 2013 at 16:22:52 UTC, Gary Willoughby wrote:
>> >>On Monday, 4 November 2013 at 15:58:48 UTC, Chris wrote:
>> >>>"Who D is Not For
>> >>>- As a first programming language - Basic or Java is more
>> >>>suitable for beginners. D makes an excellent second language
>> >>>for intermediate to advanced programmers."
>> >>>(http://dlang.org/overview.html)
>> >>
>> >>I'd argue against this. I think D would make a terrific first
>> >>language.
>> >(...)
>> >>
>> >>Something like C or D (i'd opt for D) should be any devs first
>> >>language. Simply to educate them in the basics.
>> >
>> >I would say that it really depends on the age too. D as a first
>> >language for an 18 year-old technically savvy person might work,
>> >but for a 10 year-old?
>> 
>> Well I was looking at Z80 Assembly code at the age of 12.
>
> I started programming Applesoft BASIC around that age too, and when I
> was 14 or so, I was programming in Motorola 6502 assembly language. When
> I was 16 one of my assembly programs was sold in a bookstore. Thereafter
> I moved on to Intel 8088 assembly language. It was only years later, in
> college, that I learned C and C++.
>
> I think BASIC introduced me to the concept behind imperative
> programming, even if at the time it has almost no structured constructs
> and most programs were just GOTO spaghetti soup. Going from there to
> assembly language was actually not that much of a stretch, and with big
> performance payoffs, too.
>
> Of course, the world has moved on since those days, so nowadays we don't
> usually bother with that level of performance fine-tuning except in
> performance critical bits of code.
>
> But anyway, w.r.t. the OP, if I were to be in charge of designing a
> curriculum, I'd put assembly language as the first language to be
> learned, followed by a good high-level language like D. On this, I agree
> with Knuth's sentiments:
>
> 	By understanding a machine-oriented language, the programmer
> 	will tend to use a much more efficient method; it is much closer
> 	to reality. -- D. Knuth
>
> 	People who are more than casually interested in computers should
> 	have at least some idea of what the underlying hardware is like.
> 	Otherwise the programs they write will be pretty weird. -- D.
> 	Knuth
>
>
> T

If someone doesn't know assembly, this book might help "Write Great Code, Volume 2: Thinking Low-Level, Writing High-Level".

http://www.amazon.com/Write-Great-Code-Volume-High-Level-ebook/dp/B008Z6ASGC/ref=sr_1_2?ie=UTF8&qid=1383644591&sr=8-2&keywords=thinking+low+level

At least one can get an idea of what's going on under the hood. My old man was programming with assembly for a while and told me that the suicide rate among assembly programmers was quite high.

He also told me about the rule of diminishing returns*. If with well written C program you can get 90% of assembly's performance, leave it at that. If you wanna get the remaining 10% and use assembly instead, the cost of it may not be worth the returns.

*(http://en.wikipedia.org/wiki/Diminishing_returns)

On Monday, 4 November 2013 at 17:12:34 UTC, PauloPinto wrote:
> On Monday, 4 November 2013 at 16:49:10 UTC, simendsjo wrote:
>> On Monday, 4 November 2013 at 16:22:52 UTC, Gary Willoughby wrote:
>>> On Monday, 4 November 2013 at 15:58:48 UTC, Chris wrote:
>>>> "Who D is Not For
>>>> - As a first programming language - Basic or Java is more suitable for beginners. D makes an excellent second language for intermediate to advanced programmers."
>>>> (http://dlang.org/overview.html)
>>>
>>> I'd argue against this. I think D would make a terrific first language.
>> (...)
>>>
>>> Something like C or D (i'd opt for D) should be any devs first language. Simply to educate them in the basics.
>>
>> I would say that it really depends on the age too. D as a first language for an 18 year-old technically savvy person might work, but for a 10 year-old?
>
> Well I was looking at Z80 Assembly code at the age of 12.

ohhh, i see yet another e-biceps thread.
so the older architecture i know assembly for, the bigger my biceps is?

also Paulo, something doesnt play right here. from what you were saying about things you have done and when, i've gathered, that you should be something about 80 years old by now.

On Monday, 4 November 2013 at 17:11:08 UTC, Dicebot wrote:
> On Monday, 4 November 2013 at 16:22:52 UTC, Gary Willoughby wrote:
>> Something like C or D (i'd opt for D) should be any devs first language. Simply to educate them in the basics.
>
> In Soviet Russia you do assembly in primary school :)

not sure how much true it is in XXI century, but its funny how our profesor of computer architectures (who originates from Ukrain) assumes that we were taught physics in primary school. No, we were gathering pokemon cards, playing football and fighting each other in primary school for fuck sake

On Tuesday, 5 November 2013 at 01:15:11 UTC, Walter Bright wrote:
> On 11/4/2013 2:34 PM, Era Scarecrow wrote:
>>  I did x86 Assembly language at 14.
>
> Bah. I programmed the Apollo lunar module computer for NASA when I was 8.

that is nothing. We were squashing atoms by hand in CERN with Paulo when we were 5.

back to the topic.

i wonder how big earnings in Soctiomantic are, given that you are told to program in rather exotic programming language (exotic as non-main stream enough).

On 11/05/2013 11:56 AM, t-dog wrote:

+1

> A major part of the problem is Java's religious fervor for OO. There's a natural tendency for the students to end up being taught OO *before* they have a sufficient grasp on flow-of-execution

Unhappily, a lot of Java developers out there in enterprise
computing do some kind of programming with classes, rather than
OO. For example, some framework developer intended the users to
overwrite some inherited method in their concrete subclass. As
this is not understood people do some tricks with reflection or
even byte code manipulation. When you show them that they only
need to overwrite the inherited method, then first call super and
then add their own stuff, they are surprised. And some of those
people are now architects and your boss. Oh my, oh my...

That's a reason many Java developers look at Scala as an
alternative JVM language or at something else, because it is
simply not fun any more ...

I think the first language for CS students should be one without
garbage collection. It is important to understand what a big win
a GC is if the siutation permits using one.

-- Bienlein

On 2013-11-05 12:41, Bienlein wrote:

> Unhappily, a lot of Java developers out there in enterprise
> computing do some kind of programming with classes, rather than
> OO. For example, some framework developer intended the users to
> overwrite some inherited method in their concrete subclass. As
> this is not understood people do some tricks with reflection or
> even byte code manipulation. When you show them that they only
> need to overwrite the inherited method, then first call super and
> then add their own stuff, they are surprised. And some of those
> people are now architects and your boss. Oh my, oh my...

Someone would understand byte code manipulation but not inheritance? Seems very strange.

-- 
/Jacob Carlborg

> Someone would understand byte code manipulation but not inheritance? Seems very strange.

Ah, you think it seems unbelievable? I thought so too the first
time. OOP and OOD is not on the job ads any more as earlier. They
are now filled with things like JSP, JSF, EJBs, JNDI, JTA, JMS,
SOAP, REST, ICEFaces, Spring, Ajax, OSGi, Spring, Axis, CXF,
Oracle, Sybase, DB/2, Oracle, MS-SQL, MySQL, Hibernate, Quartz,
JMeter, XSD, XSLT, JavaScript, etc.

So people after graduating are busy like hell learning some of
those things to get a job. That leaves absolutely no time to
learn OOP/OOD. So once they managed to get a job, they have to
find ways to get the work done to keep it.

Recruiters don't understand that OOP/OOD is a base technology and
many companies don't, either. A lot of Java work is getting some
coding work done. If you got that web service implemented in less
than 5 hours, then you are good. Otherwise you are bad. Nobody
will look at the code whether it reflects some design or
something. Sad, but often true out there.

On Tuesday, 5 November 2013 at 12:36:21 UTC, Bienlein wrote:
>> Someone would understand byte code manipulation but not inheritance? Seems very strange.
>
> Ah, you think it seems unbelievable? I thought so too the first
> time. OOP and OOD is not on the job ads any more as earlier. They
> are now filled with things like JSP, JSF, EJBs, JNDI, JTA, JMS,
> SOAP, REST, ICEFaces, Spring, Ajax, OSGi, Spring, Axis, CXF,
> Oracle, Sybase, DB/2, Oracle, MS-SQL, MySQL, Hibernate, Quartz,
> JMeter, XSD, XSLT, JavaScript, etc.
>
> So people after graduating are busy like hell learning some of
> those things to get a job. That leaves absolutely no time to
> learn OOP/OOD. So once they managed to get a job, they have to
> find ways to get the work done to keep it.
>
> Recruiters don't understand that OOP/OOD is a base technology and
> many companies don't, either. A lot of Java work is getting some
> coding work done. If you got that web service implemented in less
> than 5 hours, then you are good. Otherwise you are bad. Nobody
> will look at the code whether it reflects some design or
> something. Sad, but often true out there.

I'm not really surprised, given that employers (especially big companies) love buzz words. It's the same everywhere, not just in computing.

On Tue, Nov 05, 2013 at 11:05:40AM +0100, Chris wrote: [...]
> If someone doesn't know assembly, this book might help "Write Great Code, Volume 2: Thinking Low-Level, Writing High-Level".
> 
> http://www.amazon.com/Write-Great-Code-Volume-High-Level-ebook/dp/B008Z6ASGC/ref=sr_1_2?ie=UTF8&qid=1383644591&sr=8-2&keywords=thinking+low+level
> 
> At least one can get an idea of what's going on under the hood. My old man was programming with assembly for a while and told me that the suicide rate among assembly programmers was quite high.

I'm not surprised. Assembly programs tend to explode in complexity exponentially as code size increases. You can only go so far before the whole thing becomes unmanageably complex, at which point the only way to continue is to start fixing calling conventions, naming conventions, data structure storage formats, etc., i.e., reinvent C.


> He also told me about the rule of diminishing returns*. If with well written C program you can get 90% of assembly's performance, leave it at that. If you wanna get the remaining 10% and use assembly instead, the cost of it may not be worth the returns.
[...]

Well yes. My point was not to force students to write *all* their code in assembly, but to give them some experience in writing small(!) assembly programs so that they get a taste of how the machine actually works under the hood. Once they have that down, I'd move straight on to a nice high-level language like D, because in 90% of the code you write, you don't *need* the kind of performance direct assembly coding gives you.

That's why GCC has inline assembly extensions, and D has built-in asm blocks: for the most part, you just write in high-level D, but for the few bits of performance-critical code, you have the option of directly writing in assembly.

Writing *everything* in assembly is a big waste of time, because 90% of your code isn't part of the performance bottleneck, so you're just making yourself suffer the tedium of assembly coding for basically zero benefit. By writing the non-critical parts of the code in a high-level language, you get huge savings on your development cost, but in the 10% of the code where performance actually matters, writing in assembly can win you huge performance gains.

The same argument goes for the GC: 90% of applications out there don't *need* manual fine-tuning of manual memory management; you can save so much development time (and debugging effort!) just by using the GC instead. It's only the 10% of applications that absolutely need performance guarantees, where you actually need to worry about manual memory management.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!

On Tuesday, 5 November 2013 at 12:24:21 UTC, Jacob Carlborg wrote:
> On 2013-11-05 12:41, Bienlein wrote:
>
>> Unhappily, a lot of Java developers out there in enterprise
>> computing do some kind of programming with classes, rather than
>> OO. For example, some framework developer intended the users to
>> overwrite some inherited method in their concrete subclass. As
>> this is not understood people do some tricks with reflection or
>> even byte code manipulation. When you show them that they only
>> need to overwrite the inherited method, then first call super and
>> then add their own stuff, they are surprised. And some of those
>> people are now architects and your boss. Oh my, oh my...
>
> Someone would understand byte code manipulation but not inheritance? Seems very strange.

Well there is understanding and understanding. Yes it is quite common that people understand bytecode but not inheritance, from a software architecture point of view (not how it works). We even have quite a lot of instances of this in this newsgroup.