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

0 Members and 1 Guest are viewing this topic.

Offline snarkysparky

  • Regular Contributor
  • *
  • Posts: 174
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #75 on: November 01, 2016, 11:38:12 am »
C++ and Java contribute to global warming with their wasted CPU cycles over what is possible with a clean well written  C program.

Case Closed  :-DD :-DD :-DD
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #76 on: November 01, 2016, 11:42:40 am »
I would agree - but what is the criteria that specifies the endpoint?  If it is an academic exercise to teach OOP, then you may be right (I'm not familiar enough with what's on offer to comment any further).  However, if it is to skill up someone going into a C++ environment, then there's no need to look any further.

I think what guys like me are saying is that the whole point of C++ is that it's an extension to C. Without C, no one would ever in a million years use C++ because it's an absolutely awful OOP style language. On the other hand, if you throw out all of the garbage that comes with C++ and just use the basic OO features combined with standard C programming, C++ now becomes an extremely usable and powerful language.
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 444
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #77 on: November 01, 2016, 11:48:27 am »
C++ and Java contribute to global warming with their wasted CPU cycles over what is possible with a clean well written  C program.

Case Closed  :-DD :-DD :-DD

How about all the farting programmers required to keep the thing from dumping core ;)

Actually I agree. I just used an old piece of C to rip through a 3 million line 4.2Gb text file and find me some text in under the JIT time of a Java program...
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18010
  • Country: nl
    • NCT Developments
Re: "Stop Teaching C" - Kate Gregory
« Reply #78 on: November 01, 2016, 12:08:28 pm »
(It's a shame that strings in the C++ sense are so ... incompatible with deep embedded systems.  And that's a bit strange; they worked OK in BASIC on far less powerful computers, didn't they?   There would be so many fewer problems in the Arduino world if their String types actually worked well.)
Well.. nothing stops you from creating your own string type.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #79 on: November 01, 2016, 12:10:53 pm »
I think I disagree with her WRT
"use the debugger to look at results"
vs learning printf(); printf() may be awful,
but not having your results actually print out is ...
not satisfying

that's evil and you know why
"use the debugger to look at results"
is the best advice ever!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #80 on: November 01, 2016, 12:18:09 pm »
in my case string_t is a struct
which includes the length
and the current position

also being a type implies methods
{ compare, assign, append, … }

therefore if (msg isEqualTo "hallo") makes sense
as long as "hallo" + " " + "world"

it consumes +8 bytes
and a few more cycles(1) to fetch out the method

what is the problem about that?


edit:
(1) checked now, +10 cycles
« Last Edit: November 01, 2016, 01:36:43 pm by legacy »
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9206
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #81 on: November 01, 2016, 12:35:17 pm »
(It's a shame that strings in the C++ sense are so ... incompatible with deep embedded systems.  And that's a bit strange; they worked OK in BASIC on far less powerful computers, didn't they?   There would be so many fewer problems in the Arduino world if their String types actually worked well.)
Well.. nothing stops you from creating your own string type.
we dont need a new language. what we need is a unified data type and safe coding style education. but well, everybody like to make their own philosophy...
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #82 on: November 01, 2016, 12:43:27 pm »
Code: [Select]
ev-lang/gnat-gcc-4.6.4/image//usr
mkdir -p -- /var/tmp/portage/dev-lang/gnat-gcc-4.6.4/image//usr /var/tmp/portage/dev-lang/gnat-gcc-4.6.4/image//usr
/bin/sh: line 3: cd: host-i686-pc-linux-gnu/fixincludes: No such file or directory
Makefile:4750: recipe for target 'install-fixincludes' failed
make[1]: *** [install-fixincludes] Error 1
make[1]: Leaving directory '/var/tmp/portage/dev-lang/gnat-gcc-4.6.4/work/gcc-4.6.4'
Makefile:2689: recipe for target 'install' failed
make: *** [install] Error 2
 * ERROR: dev-lang/gnat-gcc-4.6.4::gentoo failed (install phase):
 *   emake failed
 *

may Saint Kate Gregory help me :palm: :palm: :palm: :palm:
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10269
  • Country: gb
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #83 on: November 01, 2016, 12:46:16 pm »
(It's a shame that strings in the C++ sense are so ... incompatible with deep embedded systems.  And that's a bit strange; they worked OK in BASIC on far less powerful computers, didn't they?   There would be so many fewer problems in the Arduino world if their String types actually worked well.)
Well.. nothing stops you from creating your own string type.

That's the problem: many people have done just that, badly and incompatibly.

The same is true for anything to do with time and dates.
« Last Edit: November 01, 2016, 12:53:14 pm by tggzzz »
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 tggzzz

  • Super Contributor
  • ***
  • Posts: 10269
  • Country: gb
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #84 on: November 01, 2016, 12:52:15 pm »
We're getting away from the point of the video....

For beginners on their way to learning C++, getting them to learn C first is going to make it harder to get into C++, as you've already taught them to think the wrong way.

If you want to teach an object-oriented language, then loading them up with archaic and inappropriate techniques is just making their journey harder and absolutely confusing, especially when the tendancy for thinking in object concepts is how they have been naturally processing the world up to this point.

Yes, that was the point of the video and I wouldn't quibble with it.

But if your objective is to teach an OOP language without loading them up with archaic and inappropriate techniques, then C++ is completely the wrong endpoint! Use a modern language!

I would agree - but what is the criteria that specifies the endpoint?  If it is an academic exercise to teach OOP, then you may be right (I'm not familiar enough with what's on offer to comment any further).

I've been using C since 1981, Smalltalk since 1986, C++ since 1988, Objective-C since 1988, and Java since 1996. Plus quite a few other domain-specific languages :) The more radically different languages you know, the less likely you are to try to insert a screw with a hammer.

Quote
However, if it is to skill up someone going into a C++ environment, then there's no need to look any further.

Skilling someone up sufficiently that they can be safe and productive in C++ requires much more than a short course. Hells teeth, there's ample evidence even the "designers" don't fully understand their creation!
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 legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #85 on: November 01, 2016, 01:00:49 pm »
there's ample evidence even the "designers"
don't fully understand their creation!

and ... the explanation given by their project manager is
because they haven't  (properly) used AADL, ain't it ?  :-DD
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #86 on: November 01, 2016, 01:04:53 pm »
p.s.
just for my curiosity, do you/your team use Stood for your own designs?
if yes, is it really helpful?
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #87 on: November 01, 2016, 02:37:38 pm »
Kate Gregory's Blog looks very interesting  :-+
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #88 on: November 01, 2016, 03:05:49 pm »
Kate says Yes on Lambdas in C++
and she promotes the use,
but I haven't yet understood if
I really like this C++11 feature  :-//
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7242
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #89 on: November 01, 2016, 03:09:59 pm »
based on a lexer and parser that is so stupid
it needs semicolons to figure out where a line ends

I don't agree, the problem is not the semicolon at the end of the line
the problem is the C grammar itself which allows silly constructs
it goes deeper than that.

have you ever wondered why there is a need for .h files ?

The c compiler had to run on a machine with very little memory. this was a shared user machine and as students they were only allocated a small amount of resources....
They designed the compiler as single pass. simply because anything else didn't fit and was too complex. Same goes for that stack/heap construct.
all the c compilers compile for this 'virutal model and then shoehorn the output on the target architecture. this is not optimal. memory is not laid out that way on all machines.

Take a look at header files. In 2016 that is the most stupid thing ever (when the language was create it was not !). As a human ,i have to declare the functions in the header file ,and then write the same construct once again in the real code section. Why do i need to forward declare functions ? i don;t know what the final format of those functions will be ! i have not designed them yet ! and i need to fix stuff in different files every time i make a modification to the function i/o.

Why can't the compiler just go over the source code once, collect all the functions , and then start compiling ? There is not even a need for  includes. simply go look in other files in the directory and see if you can find it there first. descend into subdirectories automatically. if files reside on a central server then you can point to them if needed.

The reason is historical . disk i/o was non exisitent ( the machine had TAPE for crying out loud... so you could not just randomly access files... ) and multipass meant eating lots of ram at compile time.. ram the machine did not have !

so we are stuck anno 2016 with a language and compilation method that was built for a long dead architecture with very limited resources.

C should evolve. Any language should evolve. compilers must be made multipass. I want to do away with all the overhead as a human. the less keyboard pounding i need to do the better. any character i type is a potential source of mistake. (speelling erroooors )

Now people will pitch in : use a good code editor with autocompletion blablabla.. that is not solving the problem, it is just a workaround ...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 444
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #90 on: November 01, 2016, 03:29:38 pm »
.h files have a purpose past that. You stick your contract with the library or program in it. Then you implement it inside the .c.

Private/internal stuff just has to be higher up the .c file. I do believe this is modular programming or whatever it was called.
« Last Edit: November 01, 2016, 03:31:34 pm by setq »
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #91 on: November 01, 2016, 03:34:16 pm »
Take a look at header files. In 2016 that is the most stupid thing ever

they are useful to describe interfaces
in ada and pascal you have to do something similar
due to the separation before interface and implementation

modular design
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1793
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #92 on: November 01, 2016, 03:34:36 pm »
In addition to providing the interface, the .h files make it possible to provide the libraries of the functions without providing the actual source code.
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #93 on: November 01, 2016, 03:36:21 pm »
Kate says Yes on Lambdas in C++
and she promotes the use,
but I haven't yet understood if
I really like this C++11 feature  :-//

Like everything else in C++, if you use it right it's convenient and powerful. Sometimes you have to generate a value, and it's more complex than a simple expression but you don't want to clutter up your code with generating it where it's just going to be used once and passed into a function. Here, the lambda function is useful. It's like a block of statements that returns a value.

It's also convenient to be able to pass a code snippet as data. So you can do things like give a function this snippet of code and say, "here, run this on all of your elements." Sure, you can do it other ways, but this particular way is very convenient and flexible.

Lambdas have been around for a LONG time. They just happen to be new to C++. I suspect that some C++ programmers out there have already figured out ways to abuse the hell out of Lambdas, but I think they're generally good things to have around.
« Last Edit: November 01, 2016, 03:41:05 pm by John Coloccia »
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7242
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #94 on: November 01, 2016, 03:51:14 pm »
In addition to providing the interface, the .h files make it possible to provide the libraries of the functions without providing the actual source code.
and why is that needed ?

if the compiler traverses all files in a directory ti will find the libraries. whether those exist as .c files or as .obj . doesn't matter.

my claim is : there is no need for includes and .h files. all the compiler has to do is look in the directory where the project is stored (and its subdirectories) and see if it can find the function, either in source or object. if it can't find it there : stop compilation.
you would only need an include statement if some stuff resides outside the project directory. then you can point to it. (now people will com up with the excuse : so a function deep in a subdirectory would still need to declare outside . no it wouldn't as compilation does not start at the low level. it starts with the main file which resides at the highest level. the compiler traverses the entire directory tree from the root point of compilation.

all headers and includes would become obsolete. no more misery with function prototypes that mismatch the actual functions. no more cleaning up missing dots and semicolons and other keyboarding mistakes that prevent the program from compiling. i want to focus on developing the actual code as opposed to fixing typing mistakes.

same goes for the stupidity with typecasting. on some compilers an in is 8 bit , on other it is 16 bit , ... why on earth does that have to change ? remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bit.... the same code overflowed in the rocket ... because the idiots who build compilers think it is ok to have different definitions for the same type....

The c language has many constructs and limitations that stem from the resource cramped machine it was developed on.  think about this whole stream.io thing. data is only a stream ... if it comes from an ff-ing tape ! who uses tape these days ?

It should evolve. ( and im not talking c++ c# evolution , those are supersets to create object oriented stuff.  i'm talking compiler intelligence and eliminating stuff that does not make sense anymore on modern machines.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #95 on: November 01, 2016, 04:01:34 pm »
As I mentioned previously C and C++ are very difficult to parse reliably. I think the .h files (or more generally forward declarations) makes the compiler's job a lot easier.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #96 on: November 01, 2016, 04:04:09 pm »
if the compiler traverses all files in a directory
it will find the libraries. whether those exist
as .c files or as .obj . doesn't matter

yes, in the theory
but it's problem when you don't provide sources

imagine you have a library with a lot of .obj
you need their public interfaces

and here we go: you need them


for my own made compiler, I am also using them
to automatically build the dependency tree

I have removed the "#include" meta statement
instead I am using "use yyyy.dep.*;"

which includes the output from the dependencies tree

yyyy is the filename of the module

e.g. lib_stdio_v1 -> lib_stdio_v1.{ body, interface, dep }

body: implementation
interface: prototypes, types, global shared variables, alias (constant)
dep: dependencies with other modules

 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #97 on: November 01, 2016, 04:12:53 pm »
Code: [Select]
ls /idp.do/mysrc/lib/

Code: [Select]
lib_basen2_v3.h
lib_basen2_v3.interface
lib_basen2_v3.o
lib_bit_set_v1.h
lib_bit_set_v1.interface
lib_bit_set_v1.o
lib_bitmap_v2.h
lib_bitmap_v2.interface
lib_bitmap_v2.o
lib_bitmap_v3.h
lib_bitmap_v3.interface
lib_bitmap_v3.o
lib_cal_stamp.h
lib_cal_stamp.interface
lib_cal_stamp.o
lib_debug_v1.h
lib_debug_v1.interface
lib_debug_v1.o
lib_endian.h
lib_endian.interface
lib_endian.o
lib_env_collector_mini_v1.h
lib_env_collector_mini_v1.interface
lib_env_collector_mini_v1.o
lib_env_disk_io_v1.h
lib_env_disk_io_v1.interface
lib_env_disk_io_v1.o
lib_env_pool_label_v1.h
lib_env_pool_label_v1.interface
lib_env_pool_label_v1.o
lib_env_pool_string_v1.h
lib_env_pool_string_v1.interface
lib_env_pool_string_v1.o
lib_env_shell_cmd_v1.h
lib_env_shell_cmd_v1.interface
lib_env_shell_cmd_v1.o
lib_env_toy_v1.h
lib_env_toy_v1.interface
lib_env_toy_v1.o
lib_env_wrapper_v1.h
lib_env_wrapper_v1.interface
lib_env_wrapper_v1.o
lib_fileIO_unix_v1.h
lib_fileIO_unix_v1.interface
lib_fileIO_unix_v1.o
lib_file_utils.h
lib_file_utils.interface
lib_file_utils.o
lib_file_utils_v2.h
lib_file_utils_v2.interface
lib_file_utils_v2.o
lib_filename_filter_v0.3.h
lib_filename_filter_v0.3.interface
lib_filename_filter_v0.3.o
lib_filename_utils_v8.h
lib_filename_utils_v8.interface
lib_filename_utils_v8.o
lib_fs_folder_level.h
lib_fs_folder_level.interface
lib_fs_folder_level.o
lib_fs_folder_level_v2.h
lib_fs_folder_level_v2.interface
lib_fs_folder_level_v2.o
lib_lexer_reserved_word_language_l1_show_v7b.h
lib_lexer_reserved_word_language_l1_show_v7b.interface
lib_lexer_reserved_word_language_l1_show_v7b.o
lib_lexer_reserved_word_language_l1_v7b.h
lib_lexer_reserved_word_language_l1_v7b.interface
lib_lexer_reserved_word_language_l1_v7b.o
lib_lexer_reserved_word_v7b.h
lib_lexer_reserved_word_v7b.interface
lib_lexer_reserved_word_v7b.o
lib_lexer_tokenize_v7b.h
lib_lexer_tokenize_v7b.interface
lib_lexer_tokenize_v7b.o
lib_lexer_v7b.h
lib_lexer_v7b.interface
lib_lexer_v7b.o
lib_linea_v2.h
lib_linea_v2.interface
lib_linea_v2.o
lib_list_handler_v1.h
lib_list_handler_v1.interface
lib_list_handler_v1.o
lib_mystring_v0.7.h
lib_mystring_v0.7.interface
lib_mystring_v0.7.o
lib_mystring_v2.h
lib_mystring_v2.interface
lib_mystring_v2.o
lib_net_udp_ip_v1.h
lib_net_udp_ip_v1.interface
lib_net_udp_ip_v1.o
lib_pico_shell_slush_addon_v4.h
lib_pico_shell_slush_addon_v4.interface
lib_pico_shell_slush_addon_v4.o
lib_pico_shell_slush_v4.h
lib_pico_shell_slush_v4.interface
lib_pico_shell_slush_v4.o
lib_pico_shell_toy_v4.h
lib_pico_shell_toy_v4.interface
lib_pico_shell_toy_v4.o
lib_progress_bar.h
lib_progress_bar.interface
lib_progress_bar.o
lib_queue_gp_v3.h
lib_queue_gp_v3.interface
lib_queue_gp_v3.o
lib_safestring_v2.h
lib_safestring_v2.interface
lib_safestring_v2.o
lib_serial2.o
lib_serial_unix_v3.h
lib_serial_unix_v3.interface
lib_serial_unix_v3.o
lib_serial_unix_v4.h
lib_serial_unix_v4.interface
lib_serial_unix_v4.o
lib_string_fuzzy_match_v1.h
lib_string_fuzzy_match_v1.interface
lib_string_fuzzy_match_v1.o
lib_tokener_fast_v8.h
lib_tokener_fast_v8.interface
lib_tokener_fast_v8.o
lib_tokener_fast_v8b.h
lib_tokener_fast_v8b.interface
lib_tokener_fast_v8b.o
lib_tokener_fussy_v8.h
lib_tokener_fussy_v8.interface
lib_tokener_fussy_v8.o
lib_tokener_language_show_v1.h
lib_tokener_language_show_v1.interface
lib_tokener_language_show_v1.o
lib_tokener_language_v1.h
lib_tokener_language_v1.interface
lib_tokener_language_v1.o
lib_tokener_v8.h
lib_tokener_v8.interface
lib_tokener_v8.o
lib_uart_unix_v5.h
lib_uart_unix_v5.interface
lib_uart_unix_v5.o
lib_udpip.h
lib_udpip.interface
lib_udpip.o
lib_unix_termio_kb_v2.h
lib_unix_termio_kb_v2.interface
lib_unix_termio_kb_v2.o
lib_unix_termio_kb_v4.h
lib_unix_termio_kb_v4.interface
lib_unix_termio_kb_v4.o
types.h

dependencies are automatically built using { .h, .interface }
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9206
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #98 on: November 01, 2016, 04:23:01 pm »
my claim is : there is no need for includes and .h files. all the compiler has to do is look in the directory where the project is stored (and its subdirectories) and see if it can find the function, either in source or object.
how do you suggest a wise thing to practice encapsulation or intellectual anonymousity of functions in a library/object/module? above all, how do you suggest another language that solves this problem but... maintain capabilities and freedom experiences to users similar to C/C++?

if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4347
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #99 on: November 01, 2016, 04:24:05 pm »
who uses tape these days ?

bad example, dude, I use tapes  :D

LTO-2-6 Ultrium technology
DLD-1-4 technology

both available for SCSI (obsolete) and SAS(modern)
usually for Unix big-iron servers and workstations

basically you are talking about DAT@SCSI.narrow.SE
and their predecessors, but I get your point
and I agree :D
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf