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

0 Members and 1 Guest are viewing this topic.

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #125 on: November 02, 2016, 10:33:37 am »
computer science, feelings of pity and sorrow for someone else's misfortune  :D

This is why my bench is analogue only. It's an escape from the insanity.

LoL, it sounds like when a customer wanted a *light dimmer* for his helicopter
and as solution I offered a very pretty cpu board with a tiny MPU aboard

I told him that I already had the firmware, it would have saved the development cost
since I would have given him a super discount, already DO178b level D compliant
and, come on, we were talking about a *light dimming*, not critical,
it could be considered "aesthetic" … but no way  |O

he didn't want to change his mind, he wanted to erase and rewind the whole project
because he wanted to see just operational amplifiers and transistors aboard

it was a very easy circuit but it also meant having to deal with TinaLT
and simulations and test reports to be made with DSO and probes

so at the end of our discussion … I tried my last chance
- can I … use a CPLD, sir? it's not a cpu, there is nor C neither assembly, it's HDL code
- No! I want to see transistors and OAmps!

I believe that with airplanes, helicopters, and trains it's actually a wonderful job :-DD
« Last Edit: November 02, 2016, 12:17:52 pm by legacy »
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #126 on: November 02, 2016, 10:35:20 am »
Yep! Current source, ramp generator, schmitt trigger, flip flop, diff amp as a comparator then a driver stage. It's already in my head, all in BJTs ;)
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #127 on: November 02, 2016, 11:36:36 am »
  • why do people (plural) use the "wrong" language for the problem
  • what is the domain for which there are no better languages

In my case, it is because I am now old and feel that most languages are fads, and the language isn't really what is of interest to me. I'm doing things for fun, and there is nothing I can't explore in C...

Old: yes :(
Fads: definitely.
Interest in language: only as far as it helps/hinders me in doing interesting things
Fun: the best justification!

Quote
When I need to I can also compile and use exactly the same code on Intel, Sparc, PowerPC and various ARM systems (using GCC) and get the benefits of a pretty good optimizing compiler.

Only if you are very careful to choose a subset where all the "implementation defined" and "nasal daemon" language constructs are completely aligned or avoided. For embedded work, that's particularly problematic where caches, multithreading, and multiprocessors are involved. Original C explicitly defined those as library problems - which is a problem for libraries which must rely on things the language explicitly leaves undefined!

I believe the latest C has finally included a "memory model", but the success of that is yet to be determined. (Even Java had to modify their memory model after a decade's experience!)
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 Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #128 on: November 02, 2016, 12:26:48 pm »
One hint for the compiler language designer: Separate the physical data type representation from the logical data type definitions. In C the type definitions mixes the logical presentation and the physical presentation: unit8_t loop_counter means that loop_counter is an unsigned char with a range 0 ... 255 and it is supposed to map to a single 8-bit byte. That is pretty pathetic. In reality the loop_counter should map to the index and the value range it is supposed to iterate. For example in pseudo code: loop_counter : array'first ... array'last. That states clearly the intention of the loop counter and the compiler is now able to detect if the loop_counter is assigned to a wrong value outside the intended value range and the compiler is able to select appropriate internal representation. The physical presentation is useful when dealing with the hardware level and the protocols dealing with registers and octets. There needs to be a way to make a mapping between the physical representation and the logical representation so that the compiler can produce necessary type checking and map the physical representation to the logical representation. 
 
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #129 on: November 02, 2016, 01:19:01 pm »
separate the physical data type representation
from the logical data type definitions

sure, well written, I agree  :D

Code: [Select]
typedef us_r16_t as subrange of uint32_t within { 0 .. 15 };

uint32_t is directly mapped into a cpu register
therefore sub-defining us_r16_t as uint8_t does not make sense

borders are embedded within the type
and they can be checked in hardware on demand
(there is a specific opcode-class to do so)

Code: [Select]
    uint32_iterator_t i; /* it can be used only inside a loop */
    us_r16_t j;

    for i within { 0 .. 4 }
    {
      ..
    }

    for j within { 0 .. 4 }
    {
      ..
    }

    for j within j'range
    {
      ..
    }


I guess this is also interesting
and already implemenmted :D
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #130 on: November 02, 2016, 01:30:10 pm »
Original C explicitly defined those as library problems
- which is a problem for libraries which must rely on things
the language explicitly leaves undefined!

umm some bells are now ringing in my head
some memories from lectures like ...
... why Threads Cannot be Implemented as a Library  :-//

haven't yet understood if C++ gives some help about that
(probably no, but ... it might be yes with C++11/14/..
I still have to study them)


btw, I don't want to deal with multiprocessing and multi threading
and I don't have caching and pipelining in my hobby plans

Arise-v2 is a pure multicycles mono core. My Choice.

even my tattoo says "if you ease your troubles, you enjoy the double"
well, it's a paint, but this is the sense, easy man, easy life  :D
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #131 on: November 02, 2016, 01:38:50 pm »
Original C explicitly defined those as library problems
- which is a problem for libraries which must rely on things
the language explicitly leaves undefined!

umm some bells are now ringing in my head
some memories from lectures like ...
... why Threads Cannot be Implemented as a Library  :-//

haven't yet understood if C++ gives some help about that

In general, no it can't, but...

Quote
(probably no, but ... it might be yes with C++11/14/..
I still have to study them)

... are, I'm lead to believe, getting there. But as I say, I'm not holding my breath. "Castles built on sand" and all that.

Quote
btw, I don't want to deal with multiprocessing and multi threading
and I don't have caching and pipelining in my hobby plans

It is closer that many people realise. Even (high-end) hobbyist FPGA boards have dual-core ARMs, each with their own cache and shared memory. Example: https://www.extremetech.com/computing/216866-know-what-a-fpga-is-then-the-snickerdoodle-is-for-you-and-better-than-the-raspberry-pi

(Yes I do realise you are also creating your own processor :) )
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 Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11534
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #132 on: November 02, 2016, 02:08:40 pm »
btw, I don't want to deal with multiprocessing and multi threading
thats why people like you, or the other guy want to invent a new language with multithread correctness support. hence this neverending pissing contest. as someone said, use the right tool for the right job. btw, no one can stop multithread programming in C/C++. this thread has gone off-topic and i hate pissing contest thread keep popping in my "unread topic" lists, just like the other unrelated threat thread in the beginner's section, because i will get tempted to reply to all this nonsense. they serve no purpose.
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 legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #133 on: November 02, 2016, 02:28:42 pm »
off-topic

I could argue "stop teaching C, C++, whatever
we need a new language, let's design it!
"

do you prefer a split into this title?
they are related, and following two topics
in my opinion will consume more time

I have understood that the original question "C++ vs C"
is just the beginning of the problem since neither of them
seems good, at leas for a good computer science course

thanks for your attention
greetings
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: "Stop Teaching C" - Kate Gregory
« Reply #134 on: November 02, 2016, 02:53:56 pm »
You should stop teaching all programming languages.
The only way to learn how to program is to start programming and IMO it doesn't make a big difference in which language you do it, as long as you get the way of thinking.
Give a student any language book to read for help in max. 15 hours and then asignments for 85 hours, instead of teaching for 85 hours and an asignment for 15 hours.

This year alone I had to read code in (for me) 8 new programming/scripting languages (most webapp stuff) and although I (luckily) do not have to write in all those languages I could still read/understand them and what they were doing (with some obscure libcalls being explained through Google). Times are changing and languages are popping up as mushrooms, we do not need anymore experts in one language, we need flexible people that can adjust and adopt any language that is put on their desk.
If I look at the twenty+ year old new employees that build the web and cloud apps they just google the solution if they are stuck.
That is currently the way that things get done in 1 month instead of 1 year (before the internet when every programmer needed all the info to do their job).
Just my two cents.
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #135 on: November 02, 2016, 03:08:29 pm »
Although the D language looks excellent, it also states it was designed for 32 bit and up.
I can find compilers for the Windows and Linux and some ARM (not an expert).

So for smaller MCU there is no support it seems.

My 2c.
Please continue with the C/C++ bashing..

:horse:   

:popcorn:

Yeah, it was never designed as an embedded language, though nothing really precludes you using it like that. You can even turn garbage collection off, and just use C mallocs if you want to. If you're careful to stay away from features that trigger garbage collection, then you're all set....or you can run garbage collection when it's convenient. But then you have to think, "what the hell's the point?" because it turns into an even worse version of C, IMHO.

I would certainly consider it for SOME embedded stuff, though, like when you're writing embedded systems code on some sort of linux/windows platform and you don't care about real-time performance.

C/C++ will rule the embedded world for some time to come. Maybe even forever. I don't actually think that's a bad thing. C/C++ is pretty much ideal for a lot of this kind of when you toss out the stupid language features and simply ignore the bulk of crap libraries it comes with.
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #136 on: November 02, 2016, 03:26:05 pm »
If one scraps the C/C++ macro preprocessor and replaces it with a much more powerful macro language engine (preferably lisp-like), one could  do quite magical stuff like generating the state machines, lists, containers, iterators, simple objects - just name it. At the top level of the design one could allocate the resources and describe the system, and at the lower level - the implementation level - the macros will produce the actual C/C++ code to be compiled by any suitable compiler. It may even be possible to implement compilation and run-time time asserts etc. so the macros can check that the parameters match the requirement and the values are within specified ranges.  Yes, I know that the early C++ compilers were actually macro-expansion compilers producing C code. This powerful macro language would be used to replace the existing macro preprocessor with hygienic macros, improved capabilities and ability to provide the real code generator. :)
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #137 on: November 02, 2016, 03:34:18 pm »
Or you could just use Lisp :)

(Note my username)
 

Offline AG6QR

  • Frequent Contributor
  • **
  • Posts: 857
  • Country: us
    • AG6QR Blog
Re: "Stop Teaching C" - Kate Gregory
« Reply #138 on: November 02, 2016, 04:24:32 pm »
You should stop teaching all programming languages.
The only way to learn how to program is to start programming and IMO it doesn't make a big difference in which language you do it, as long as you get the way of thinking.

Or you could just use Lisp :)

There are a lot of fairly similar languages (C, C++, PL/1, JAVA, Ada, Python, etc.) that are, broadly speaking, pretty nearly equivalent for the purpose of teaching the first semester or two of programming.  There are practical reasons to choose one over the other, but a student who has learned to implement a linked list in one will be able to write the same algorithm in another pretty quickly.

But not all languages are like that.

I've heard it said that any computer language worth learning is worth learning because it makes you think in a way you hadn't thought before, and you approach problems differently after you've learned it.  Certainly Lisp is one of those.  PostScript is another (it's a full general purpose programming language, not just a printer interface).  Learning any assembly language gives you insight into the architecture of the processor that you wouldn't get any other way.  If you fully grok pointers, casting, structs, and unions in C, you can approach recursive data structures in a way that you wouldn't if you knew only FORTRAN 66 (Old FORTRAN supports neither pointers nor recursion).

Pascal was developed as a teaching language.  I'd say it's sort of like "C with training wheels".  It's strongly typed.  It's a procedural language that supports recursion.  It won't let you have an out-of-bounds array reference.  It's pretty good at teaching abstract algorithms and data structures.  The original language forces you to write your entire program in one file (no header files, no separately compiled files that link together) so it's completely unsuitable for real-world large projects, though there are implementations that work around that issue.  I wouldn't recommend Pascal for any serious work, but I think it's still not a bad language for the purpose of teaching programming.

I actually think it's better to learn at least a couple of less-popular languages, not because you need to know them, but because they expand your horizons into knowing that there are ways of doing things other than the way today's most popular languages do them.
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11534
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #139 on: November 02, 2016, 04:25:55 pm »
I could argue "stop teaching C, C++, whatever
we need a new language, let's design it!
"
new language that nobody can complaint? you are dreaming.
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 legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #140 on: November 02, 2016, 04:47:18 pm »
Pascal

the first I ever learned back in '90  :D

I have seen some pascal compilers for embedded boards
and you can also find pascal compiler for 8051 boards
never tried, but I know they exist

edit: found!
here it is, Mikroe pascal, for arm!
my memory is still good :D

also, there is freepascal, used on Teensy and GBA
« Last Edit: November 02, 2016, 06:16:10 pm by legacy »
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #141 on: November 02, 2016, 04:49:31 pm »
Quote
The embedded target is still under development and only a few controllers are supported. Nevertheless, it's possible to create programs for embedded arm devices. The embedded target targets systems without any operating system and typically several kBs of RAM and several dozens of kB of flash. A typical target is the LPC family of NXP with popular members like the LPC2124 with 16 kB RAM and 256 kB flash using the ARM7 instruction set.

experimental (free-)pascal_embedded  :-//
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #142 on: November 02, 2016, 05:05:16 pm »

Think of some foundation things.

C's great, just add a library to do ______ .

I think you are not asking some thing simple here.
What is the difference when you use C's version of array vs a matching library? Just simple things like compile time _____.
Adding a library lets C compile something to do more while putting more work on programmer using library.

free_electron's complaining about header files.

Think here you need to ask, is it a language problem, a compiler problem or the tool used to create the program source?

How about it's all three for an answer.
A header file or section lets a programmer know what hooks can be used with this code with out having to read and understand all the code. To me that is a good thing. It lets many programmers work on separate parts of a program. It allows for a simpler faster compiler.

One problem is where is the key word that states this has a matching part in the header.
Some languages have a flag or key word that states this is a header part so you no longer need a separate header. Removes the need to match the header part to where it's defined, but also puts more work on programmer as you have to read all code and build the header part your self. One simple fix is normally missing, the command to Compiler/language to build a separate header.
With out flag or key word in language, programmers work load also increases with the need to match some things in header and code.

 the tool used to create the program source
This is the really sad part of the whole process. If the editor understands the language, then when you add the flag or key word stating it's part of header, the editor could maintain the matching part in the header. Programmer gets the best of it. You have a header for compiler and programmer to use with just the cost of adding flag or key word.

Need to remember that what is currently called a compiler is translator. If you look at C, A poor translator. It is too low level and too high level not counting the other bad parts. Some of the hiding at low level causes big problems or compiler bloat. Look binary integer math for example. At the binary level it's and array of bits that you do math on. Some math can create results larger then the input array of bits. Some CPU's supply almost zero cost functions when doing binary math to reduce need for some instruction steps. With C's hiding this, higher level code has problems.  Note here that an array of bits does not just = integer.

A CPU works with bits with some instructions working with array of bits.
Starting at this level gives the compiler options on how to get job done. It actually makes programmers job easer.
With array of bits, any bit size math is possible. Some will use one CPU instruction, while others can still be done using many CPU instructions. 
With array of bits, any bit size logic is possible. Some will use one CPU instruction, while others can still be done using many CPU instructions.  As the compiler gets smarter everything improves, Little simple things in compiler. The smart compiler knows that an array of bits of size ___ can have ___ states. It can create the bit masks when needed removing one source of programmer errors. 

Also need to think of what a macro preprocessor really is.
For C it's a hack to patch a poor language using text editing. A hack that can result in all source needing to be checked and recompiled again. For a language that uses type names & headers a lot of the need vanishes with proper language use. 
A simple what CPU is this code to run on at compile time removes more need. Note here that it is not a choice of one, it is a list of CPU's. In source then a case statement can then select what is needed.

I worked with a pascal compiler that had modules and a few added key words for system programming back in the 80's. The output of compiler was one file that contained the header for other pascal source to use this module, The machine code & the linking/patch information needed. The one file removed many problems like does header match the code. The header was simple to get as it looked like a text file but contained more after the end of the text. Pascal to assembly was also very easy, a simple command to compiler would take a text header as input and create a file containing assembly code needed for linking to pascal. Add needed assembly code and run through assembler and done. Assembly code that linked with pascal.

By fixing the low level problems, you have something you can easily build on. No big steps to run compiler on one CPU and generate output that can run on many different types of CPU's. The question becomes do you include code generator for all CPU's, A few or just one in the new compiler program.
If you have source for compiler, the hard part becomes what key or key word to use to add more smarts to compiler. What parts of compiler to include in editor.

Stop the compiler hiding things as only option. For binary math, an overflow error is a fact. Question is does compiler handle it here and/or does source program. For an object you then have many options. For garbage collection you have option of NONE. Compiler then knows what to show as an error when trying to use garbage collection based things with no garbage collection enabled. When you create an object, you also have options, Use default, Heap, stack, special memory area.

When you think of this foundation, not hard to add option to change rules for a section of code as long as lower level matches up at some point and helps other sections of code. It's just a key word that is needed stating what language follows.

Why create a new language when the editor makes a mess of it.
New language should be part of editor and part of compiler, interpreter with choice of may types of outputs in one program. All have a need at times.
Adding compile time checks and code generation should be part of language.
Hacking the hack needs to stop.


 
 
   




 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #143 on: November 02, 2016, 05:40:18 pm »
The question becomes do you include code generator for all CPU's

I am running my own research for hobby
therefore the answer is: no, sorry

btw, the don't look at me

there are smarter dudes around,
cleaver ans more skilled than me

so, I wonder: if we feel that both C and C++ are not good
why do we have forked the research into "Go" and "Rust"?

does they solve *the* problem? ...

they are based on Clang, therefore it's easy to support
existing CPUs, but ... those languages are not solving
*the* problem, the reason why we don't feel good
with C and C++ etc  :-//
« Last Edit: November 02, 2016, 05:57:44 pm by legacy »
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #144 on: November 02, 2016, 05:49:08 pm »
Starting at this level gives the compiler options on how to get job done. It actually makes programmers job easer.
With array of bits, any bit size math is possible. Some will use one CPU instruction, while others can still be done using many CPU instructions. 
With array of bits, any bit size logic is possible. Some will use one CPU instruction, while others can still be done using many CPU instructions.  As the compiler gets smarter everything improves, Little simple things in compiler. The smart compiler knows that an array of bits of size ___ can have ___ states. It can create the bit masks when needed removing one source of programmer errors. 

It sounds like a unrealistic fantasy - Let me riddle you this.... In this new language, what is returned by the equivalent of the sqrt(x) function, esp when x = 2.0?
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 helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #145 on: November 02, 2016, 05:53:37 pm »
It sounds like a unrealistic fantasy - Let me riddle you this.... In this new language, what is returned by the equivalent of the sqrt(x) function, esp when x = 2.0?
A generic can return whatever type its caller expects.
A really "future"-oriented language would "return" an infinite result (pun intended).
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #146 on: November 02, 2016, 05:59:54 pm »
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.

C was the first language to be honest with the programmer about that, and allowed programmers to write efficient code without knowing all the details (making it portable if written with care). That is why the language has been so well adopted and long lasting.
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 hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #147 on: November 02, 2016, 06:06:48 pm »
It sounds like a unrealistic fantasy - Let me riddle you this.... In this new language, what is returned by the equivalent of the sqrt(x) function, esp when x = 2.0?
A generic can return whatever type its caller expects.
A really "future"-oriented language would "return" an infinite result (pun intended).

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"

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!"

 
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 rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #148 on: November 02, 2016, 06:09:40 pm »
<snip>

If you fully grok pointers, casting, structs, and unions in C, you can approach recursive data structures in a way that you wouldn't if you knew only FORTRAN 66 (Old FORTRAN supports neither pointers nor recursion).

One point of view is that FORTRAN only supports pointers.  All variables are passed by reference, not by value.  To interface gfortran with C, I had to write a little shim code to dereference the gfortran's pointers and pass the values to the C code (or rewrite the serial IO library I was using).  So, I can do serial IO from FORTRAN!  I can control the world!

Fortran 90 added pointers and derived data types (structures).  Pointers are passed by reference so you get a pointer to a pointer.  Linked lists are now possible but I haven't tried this 'feature'.

Quote

Pascal was developed as a teaching language.  I'd say it's sort of like "C with training wheels".  It's strongly typed.  It's a procedural language that supports recursion.  It won't let you have an out-of-bounds array reference.  It's pretty good at teaching abstract algorithms and data structures.  The original language forces you to write your entire program in one file (no header files, no separately compiled files that link together) so it's completely unsuitable for real-world large projects, though there are implementations that work around that issue.  I wouldn't recommend Pascal for any serious work, but I think it's still not a bad language for the purpose of teaching programming.


I absolutely loved UCSD Pascal and, to this day, I play around with FreePascal on a PC.  I used the 8051 variant to code up an embedded control system several years back.  The code was elegant.

UNITS was invented to allow Pascal to have separately compiled units.

At one time I was working on an FPGA project to implement Niklaus Wirth's P4 output code directly in hardware.  I managed to implement all of the required instructions but it didn't occur to me at the time how I would implement system calls.  Today, I would use one of the Zynq devices and use the ARM component to implement system calls and the FPGA fabric to interpret the P4 code.  The system would absolutely rip!

"Algorithms Plus Data Structures Equals Programs" by Wirth is probably the best introductory programming text ever written.  I haven't followed along with the Modula2 and Oberon successors.  Oberon is available for embedded programming.

Quote
I actually think it's better to learn at least a couple of less-popular languages, not because you need to know them, but because they expand your horizons into knowing that there are ways of doing things other than the way today's most popular languages do them.

I still write a little FORTRAN from time to time.  It's a language I enjoy and the first I ever learned back in '70.  I'm not so enamored of the later additions of objects but I do like the syntax cleanup.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #149 on: November 02, 2016, 06:53:04 pm »
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.

C was the first language to be honest with the programmer about that, and allowed programmers to write efficient code without knowing all the details (making it portable if written with care). That is why the language has been so well adopted and long lasting.

What you are describing is the "high level assembler" concept, with "close to silicon" abstractions. That's justifiable, fine and dandy. Arguably C is still the best for that.

There are also many languages (especially Java and Python) aimed at "general purpose application-domain" abstractions that are far removed from the silicon. That's also justifiable, fine and dandy. They are a damn sight better than C for those purposes; hence the explosion in their popularity.

But the real serious unresolvable dichotomy is that C (and deliberately in the case of C++) has mutated into something that attempts to do both and ends up doing both poorly. It has become unnecessarily complex for the "high level assembler" use case, and has too many badly defined constructs and leaky abstractions for the general purpose application use case.

The reasons for its longevity and adoption are more to do with history than technical merit. "Science advances one death at a time"; the same can be said for programming.
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
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf