Author Topic: "Stop Teaching C" - Kate Gregory  (Read 43976 times)

0 Members and 2 Guests are viewing this topic.

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #150 on: November 02, 2016, 07:02:13 pm »
@tggzzz
what do you think about
  • Rust by Graydon Hoare (Mozilla)
  • Go by Rob Pike and Ken Thompson (Google)
  • Caml by Xavier Leroy, Jerome Vouillon e Damien Doligez (INRIA.)

do I'd better loot at them?
skip? leading to damnation?
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #151 on: November 02, 2016, 07:08:07 pm »
That is just waving the problem off... say a user is expecting to see the answer... "print sqrt(18)" what does your language give? "4"?, "3*sqrt(2.0)", an endless stream of digits? or "Sorry Dave, that answer can not be computed with the time left in the universe"
That seems like an obvious case, but mixing user interface code with calculation is a jumbling of concerns and is bad design. In the MVC paradigm, the code that does the calculating (the model) shouldn't be too concerned with how the results will be displayed (the view). The view for a calculator program can truncate results to fit its window.

Quote
Or even worse
  i = sqrt(2.0)
  print "The square root of 2.0 is " i
  j = i * i
  print "Hang on, i * i is " j " which either isn't 2.0, or I didn't use the number printed above when calculating it!"
Same problem, and further mixing up what should properly be separated into a controller module (inputing expressions to calculate).

Strange how many have an adversarial relationship with their computers and tools. Isn't the idea to work with the machine, not against it, to achieve your aim?

If is just that C (and I guess C++) is more up-front and honest (some say blunt and rude) and shows a machine's personality more strongly than other wishy/washy languages. Internally a computer can only do a limited set of things on a limited set of primitive data types, and hold that in memory, and on different platforms things can be different. It allows you to work with the hardware, not in spite of the hardware.
The problem is that computers exist to run programs, not the other way around. When a computer cost today's equivalent of $100 Million and ran a thousand operations per second, the low-level approach made sense. That hasn't been true in living memory, though. Since before I've been breathing, the expense of development has dwarfed the cost of the hardware, and software is much longer lived, as well. Who cares what is "the machine's personality"? You are speaking of a disposable gadget as if it were a dinner guest.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #152 on: November 02, 2016, 07:16:02 pm »
hamster_nz
Thinking of ONLY One is a problem.
sqrt(x) function returns what the caller of function wants and uses what the caller supplies.
what prevents this

error, functionresult = sqrt(x)

What says that compiler only has access to just One sqrt(x). You know that is not true now as you have sqrt(x) that returns a byte, integer, ..., real. The compiler is just selecting the proper one or generating proper code for the one needed. The compiler just needs the information to make the choice.

legacy
  Think of your list of parts.
  When you split something into two parts, you cure some problems while adding problems. Think of why the parts are there.

Why do you need a make file? For a language that has a header to a block of code, the compiler for that language knows what is needed when you compile a program. It has option of doing this it's self or passing buck to make program. It's not a one or other choice, both can do a part. In a lot of cases, one program trying to remote control a second program adds great costs for very little benefit. 

The same is true for linker. why elf, dwarf as only option. Why not one file that contains the header for many languages, code & linking information. The code is no good with out a language header, why remove it? When doing this, nothing stops you from also having a linker header or not. Also nothing stops you from having many code sections.
Linking is two parts, link at compile time and/or link at run time. For embedded, you want link at compile time. When using an OS, compile time, run time or both. Run time also adds problems of what version of code that is not present at compile time. Can the code be shared at run time? Are you just linking for the sake of linking? Granted run time does let you update a chunk of code that is not linked at compile time with the added cost of time.
   
If you look at language rules for Pascal & language rules for Oberon, you should see that less rules can make a more powerful language. Less rules also makes it easer to create a compiler.
The big problem for Pascal & UCSD Pascal was it's lack of complete foundation in the compiler. As I said, I used a pascal compiler where few problems of lack of foundation remained. 
C's answer to most things is Make the Programmer do what the compiler could do. 

If you want a fast compiler, don't add dumb things that require all code to be compiled each time. Don's leave out simple to type things that makes compiler quicker. This is really dumb when you can have the editor type a lot of this for you.
A good language would let you type code & at same time be able to access lists of options while in the editor.

A little code that can process a lot of data can be much better then a lot of code processing little. Processing data is what a CPU is good at.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19281
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #153 on: November 02, 2016, 07:17:59 pm »
@tggzzz
what do you think about
  • Rust by Graydon Hoare (Mozilla)
  • Go by Rob Pike and Ken Thompson (Google)
  • Caml by Xavier Leroy, Jerome Vouillon e Damien Doligez (INRIA.)
do I'd better loot at them?
skip? leading to damnation?

I don't have a valid opinion.

I've glanced at the first two, but haven't attempted to do anything with them. They look sensible, but... Quite frankly, the dominant considerations are the available tools, libraries and skilled personnel - all of which are a serious problem for any new language.

Sincel learning C in 1981, the only times I've jumped into using new languages are with:
  • Prolog -because you express some concepts so differently and succinctly
  • Smalltalk - on a fat Mac, the first affordable OOP
  • Objective-C - a good marriage of Smalltalk OOP with procedural concepts (unlike C++)
  • Java - because of Gosling's track record and the quality and clarity of the whitepaper. I just said "yes" to each of the design decisions, and knew it was A Good Thing
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #154 on: November 02, 2016, 08:00:10 pm »
IMHO, Go doesn't deserve to be mentioned in the same sentence as something like D or C...or even Rust. If it weren't for Google pushing it, Go wouldn't have passed the laugh test.

Rust is interesting. They certainly have better marketing than D. Overall, I think D is a more useful, general purpose language but I can certainly see where Rust has advantages.


« Last Edit: November 02, 2016, 08:02:32 pm by John Coloccia »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #155 on: November 02, 2016, 08:17:43 pm »

The big problem for Pascal & UCSD Pascal was it's lack of complete foundation in the compiler. As I said, I used a pascal compiler where few problems of lack of foundation remained. 
C's answer to most things is Make the Programmer do what the compiler could do. 


I don't want the compiler writers deciding how my program should run.  In C, I can, and indeed I am forced to, provide clues about my intent.  If I want an integer result of a real square root, well, I simply cast the result.  Now the compiler and I both agree on what the result should be.

I don't write payroll programs and I certainly don't write code to cure world hunger.  I don't need a language tailored to do either one.  I want to twiddle bits in a register and make LEDs blink (or some similar but more sophisticated example).  I'm perfectly happy with a language that doesn't force me to use a heap (if I ignore certain library functions) and I have no problem telling the linker exactly where to put the code and data.  In fact, for embedded programming, I am forced to tell the linker because every chipset is different.

Makefiles allow me to use alternative libraries, compile for different execution environments (debug versus release), different chipsets, even different compilers and so on.  FWIW, Eclipse is doing a pretty nice job of generating simple Makefiles.  Makefiles also handle partial compilation based on revision date/time.  If I only change one file, there is no need to compile the entire tree.

The reason C is still hanging around (and the same for FORTRAN) is that, in their domain, they are the best tools to use.  Nobody would keep hanging on to FORTRAN for 60 years if it didn't provide a service.  Inertia would have been overcome decades ago.  Same story for C.  Yet, here we are, still using both.  Gigantic chunks of code are still being written in C.

What the world needs is a decent application language.  C++ isn't it!  In my view, neither is Java.  I can't imagine writing a really large program in Python (large, like a 3D CAD program). I have no idea what such a language would look like.  The problem is to provide the features without the complexity.


 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #156 on: November 02, 2016, 08:41:21 pm »
The problem is that computers exist to run programs, not the other way around. When a computer cost today's equivalent of $100 Million and ran a thousand operations per second, the low-level approach made sense. That hasn't been true in living memory, though. Since before I've been breathing, the expense of development has dwarfed the cost of the hardware,  Who cares what is "the machine's personality"? You are speaking of a disposable gadget as if it were a dinner guest.
I'ld rather spend my spare time with a dinner guest who can show me interesting things, then one completely lacking in personality.  :D

You mustn't be working on any interesting problems in interesting domains:

- CUDA has personality
- SIMD has personality
- Multiprocessing can be psychopathic,
- Mixed HDL / Software development is sometimes like having genius preschoolers at university

If you are not bumping into these edges you are not pushing very hard. I regularly have less CPU cycles than I want or need - esp for DSP stuff.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1663
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #157 on: November 02, 2016, 09:00:19 pm »
What the world needs is a decent application language.  C++ isn't it!  In my view, neither is Java.  I can't imagine writing a really large program in Python (large, like a 3D CAD program). I have no idea what such a language would look like.  The problem is to provide the features without the complexity.

Agreed. I've been looking for the ideal application language for 35 years and I haven't found it yet. C++ is an abomination. Java isn't much better. C# is a step in the right direction, but not there yet. I'm still holding out hope that some of the new languages that I haven't looked at yet (Rust, Swift, Go) might be the answer, but based on past experience I'm not holding out too much hope.

In the embedded arena, I've been reasonably happy with C and don't see any need to go to a more complex language (heaven forbid C++) for embedded work.
Complexity is the number-one enemy of high-quality code.
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: "Stop Teaching C" - Kate Gregory
« Reply #158 on: November 02, 2016, 09:22:04 pm »
What the world needs is a decent application language.  C++ isn't it!  In my view, neither is Java.  I can't imagine writing a really large program in Python (large, like a 3D CAD program). I have no idea what such a language would look like.  The problem is to provide the features without the complexity.

Agreed. I've been looking for the ideal application language for 35 years and I haven't found it yet. C++ is an abomination. Java isn't much better. C# is a step in the right direction, but not there yet. I'm still holding out hope that some of the new languages that I haven't looked at yet (Rust, Swift, Go) might be the answer, but based on past experience I'm not holding out too much hope.

In the embedded arena, I've been reasonably happy with C and don't see any need to go to a more complex language (heaven forbid C++) for embedded work.

Swift is actually very nice as an application development language. The initial version still had a few, um, idiosyncrasies, but most of that has been fixed with Swift 2.0.

It's like someone plucked all the good parts of ObjC, C#, Python and RoR, then put them in a blender.

The compiler is available for Linux now, you should give it a try! (It's been mostly ported to ARM as well; someone has nightly builds targeting BeagleBone and Raspberry Pi 2/3, but I think it only supports Ubuntu at the moment, which is less than ideal.)
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #159 on: November 02, 2016, 10:04:08 pm »

The big problem for Pascal & UCSD Pascal was it's lack of complete foundation in the compiler. As I said, I used a pascal compiler where few problems of lack of foundation remained. 
C's answer to most things is Make the Programmer do what the compiler could do. 


I don't want the compiler writers deciding how my program should run.  In C, I can, and indeed I am forced to, provide clues about my intent.  If I want an integer result of a real square root, well, I simply cast the result.  Now the compiler and I both agree on what the result should be.
You should ask your self which is better, get what you want creating code with bugs and not being told of the bug errors or get what you want and being informed of the errors.
A good language does not prevent you from getting what you want.
A simple  = integer(real square root) does what you want above.

Quote
I don't write payroll programs and I certainly don't write code to cure world hunger.  I don't need a language tailored to do either one.  I want to twiddle bits in a register and make LEDs blink (or some similar but more sophisticated example).  I'm perfectly happy with a language that doesn't force me to use a heap (if I ignore certain library functions) and I have no problem telling the linker exactly where to put the code and data.  In fact, for embedded programming, I am forced to tell the linker because every chipset is different.

Makefiles allow me to use alternative libraries, compile for different execution environments (debug versus release), different chipsets, even different compilers and so on.  FWIW, Eclipse is doing a pretty nice job of generating simple Makefiles.  Makefiles also handle partial compilation based on revision date/time.  If I only change one file, there is no need to compile the entire tree.
  alternative libraries only work when they are compatible to source.
Compiler is program that can state if this works or not.

Think of your debug
A better option that does not prevent total debug is a language where you can state,
I want to debug this type, this structure, this function. this part of code.
Again your make file debug option is the poor choice. 

Your whole thing here is move information to a point where language is less or no help to you instead of where a language could help.
Guess you like increasing your work load.

Quote
The reason C is still hanging around (and the same for FORTRAN) is that, in their domain, they are the best tools to use.  Nobody would keep hanging on to FORTRAN for 60 years if it didn't provide a service.  Inertia would have been overcome decades ago.  Same story for C.  Yet, here we are, still using both.  Gigantic chunks of code are still being written in C.

What the world needs is a decent application language.  C++ isn't it!  In my view, neither is Java.  I can't imagine writing a really large program in Python (large, like a 3D CAD program). I have no idea what such a language would look like.  The problem is to provide the features without the complexity.
A good language can go to lower level then C while also telling you about coding errors. It can also work at a higher level then C.
Type name checking is a simple concept that can show a lot of errors in source, done correctly does not prevent the stupid assignment of a voltage to a temperature variable. 
 
The point is a language can not help if you do not give it the information needed to help.



 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #160 on: November 03, 2016, 12:50:49 am »
... Looks like Perl laid a turd in the middle of the symbol table. And all the other shit it has to bring in just to talk to a stream. And that's the tangle that C++ leaves you in all the time. Ugh kill me.

No need to get killed. That's called "name mangling" and it enables C++ to represent it's more complicated notion of symbols in the same namespace that C uses. To get back your programmer readable names, pipe readelf output through a program called "c++filt".
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #161 on: November 03, 2016, 02:47:29 am »
No need to get killed. That's called "name mangling" and it enables C++ to represent it's more complicated notion of symbols in the same namespace that C uses.
Yes, C++ requires this mangling. BUT there is no standard, so interoperability of libraries with different compilers is nil :(
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #162 on: November 03, 2016, 03:22:24 am »
Yes, C++ requires this mangling. BUT there is no standard, so interoperability of libraries with different compilers is nil :(
If you say so.  :-//  I've never had a problem with it, but most "libraries" I use are distributed in source or via straight C calling conventions.
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #163 on: November 03, 2016, 07:42:51 am »
IMHO, Go doesn't deserve to be mentioned in the same sentence as something like D or C...or even Rust. If it weren't for Google pushing it, Go wouldn't have passed the laugh test.

Indeed. It's a fine language to code yourself into a corner with.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19281
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #164 on: November 03, 2016, 08:20:58 am »
Yes, C++ requires this mangling. BUT there is no standard, so interoperability of libraries with different compilers is nil :(
If you say so.  :-//  I've never had a problem with it, but most "libraries" I use are distributed in source or via straight C calling conventions.

Oh, you lucky person. For me that's only been the case with "small" projects.

But that's one reason why the number and scope of commercial libraries in C/C++ is dwarfed by those in more modern languages, especially Java.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #165 on: November 03, 2016, 09:11:29 am »
Yes, C++ requires this mangling. BUT there is no standard, so interoperability of libraries with different compilers is nil :(
If you say so.  :-//  I've never had a problem with it, but most "libraries" I use are distributed in source or via straight C calling conventions.

He's absolutely right. There is not standard, and in fact it's important that you don't use different compiler/linkers when using C++ because there are other implementation details that are also undefined. It's a good thing that everything resolves to an unknown reference or you'd end up linking together bits of code that are binary incompatible and it would be a disaster.

Some compilers have made themselves compatible by convention, but it's only convention and nothing else.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #166 on: November 03, 2016, 09:50:35 am »
it only supports Ubuntu at the moment

yep, the get started appears here, and

Quote
Linux

Requirements
Ubuntu 14.04 or 15.10 (64-bit)
Supported Target Platforms
Ubuntu 14.04 or 15.10 (64-bit)

concerning linux, only ubuntu is in the list

edit:

and (stupid me) ...

Code: [Select]
swift-v2.2 # file usr/bin/swift

Code: [Select]
usr/bin/swift: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.24,
BuildID[sha1]=5fd987725e5349f6c7aa7706e8c0e5c2c325fe9d
not stripped

… my x86 laptop is 32bit :palm: :palm: :palm:
« Last Edit: November 03, 2016, 09:54:18 am by legacy »
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11537
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #167 on: November 03, 2016, 10:01:29 am »
my x86 laptop is 32bit my laptop is x86
fixed that for you...
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
"Stop Teaching C" - Kate Gregory
« Reply #168 on: November 03, 2016, 11:38:13 am »
it only supports Ubuntu at the moment

yep, the get started appears here, and

Quote
Linux

Requirements
Ubuntu 14.04 or 15.10 (64-bit)
Supported Target Platforms
Ubuntu 14.04 or 15.10 (64-bit)

concerning linux, only ubuntu is in the list

edit:

and (stupid me) ...

Code: [Select]
swift-v2.2 # file usr/bin/swift

Code: [Select]
usr/bin/swift: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.24,
BuildID[sha1]=5fd987725e5349f6c7aa7706e8c0e5c2c325fe9d
not stripped

… my x86 laptop is 32bit :palm: :palm: :palm:

Not exactly what I meant... There's a group working on an ARM port; they have a nightly build available for download, but it only seems to support bleeding edge Ubuntu at the moment. (Perhaps because it already comes with LLVM and a bunch of other pre-reqs.)

That said, there at least two separate other ports available, both with build scripts that work on any distro with the required tools. The issue is the build can take up to 12 hours on a Raspberry Pi 3!

As for the official Swift binaries, I'm sure they're x64, but nothing should be stopping you from compiling it yourself on x86. There's also no reason that the x64 binaries won't work on other distros, either.  (Assuming all the prerequisites are in place).

Apparently the reason Ubuntu is on their list is because that's the distro they happen to use for their Linux development. Keep in mind that up until like a year ago, it wasn't even available for Linux! I'm sure in a few years, they'll have binary installs for all the major package managers (Yum, apt, fetch, etc.)
« Last Edit: November 03, 2016, 11:40:36 am by timb »
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #169 on: November 03, 2016, 12:07:27 pm »
but nothing should be stopping you
from compiling it yourself on x86

yep, yesterday I compiled gnat on my gentoo box
(with a lot of fighting in the middle … dammit gentoo)
It would have been a lucky event to find some x86-32
already done, ready out the box

not yet happened, I still have hope :D

There's also no reason that the x64 binaries
won't work on other distros, either.
(Assuming all the prerequisites are in place).

yes, I see, it's just a matter of time
I have to create an ebuild inside an overlay
(gentoo terms) fix it, test it, emerge it etc

long time story, 2 or 3 working days at least

I need a "time doubler" machine , or, still better
a cloning machine, two is better than one :D
« Last Edit: November 03, 2016, 12:15:12 pm by legacy »
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #170 on: November 03, 2016, 12:09:24 pm »
BTW Swift seems THE language 
is it the one? good question :D

"Stop Teaching C" + "teach Swift"
(might it be? who knows …)
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #171 on: November 04, 2016, 04:52:24 am »
BTW Swift seems THE language 
is it the one? good question :D

"Stop Teaching C" + "teach Swift"
(might it be? who knows …)
Don't think there is such a thing as "the one" language. But Swift is pretty interesting. It's got a lot of the good parts of C++ with some of the sharp edges removed. Documentation is insufficient right now. And it won't be the tool of choice for mcus because it depends on dynamic memory allocation.
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12288
  • Country: au
Re: "Stop Teaching C" - Kate Gregory
« Reply #172 on: November 05, 2016, 12:41:59 pm »
Somewhere buried in this thread is the original topic... a matter of a re-think on how to teach a language...

... not whether it's any better or worse than another.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: "Stop Teaching C" - Kate Gregory
« Reply #173 on: November 05, 2016, 12:49:32 pm »
Somewhere buried in this thread is the original topic... a matter of a re-think on how to teach a language...

The original topic was in how to better teach C++. I think it's blatantly obvious that teaching how to write consistent C++ code using the standard C++ mechanisms is better served by directly starting with C++. With the blatantly obvious out of the way we moved on to the desirability of doing so immediately (ie. not).

IMO programming should be taught by pseudo-code with assembly language implementation, teach them about micro-optimization (with a focus on memory coherency) at that level. Then skip C/C++ entirely and move up the abstraction chain to java or some fashionable high level language du jour. As much as I hate Apple, all the students are sitting there with macbooks any way ... so I guess swift would make sense.
« Last Edit: November 05, 2016, 01:04:56 pm by Marco »
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: "Stop Teaching C" - Kate Gregory
« Reply #174 on: November 05, 2016, 01:02:05 pm »
Seen few minutes of the video: What a bullshit that is. Yeah. Just stop teaching anything, because it requires to learn.  :palm:

 
The following users thanked this post: amyk, gocemk, XFDDesign


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf