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

0 Members and 1 Guest are viewing this topic.

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #125 on: November 02, 2016, 10:03:53 am »
I'm pretty sure that's true of MIPS64 as well

yes, I confirm it, it's a big mess with MIPS64

I have recently bought a few cpu modules for my Malta board

although "CoreLV-5KC" sounds like the cpu used by SGI in their Indy-station
"5K" doesn't mean "R5000"

"4KC" means MIPS32r2, "5KC" means MIPS64
the first one is a true 32bit machine, the second one is a true 64bit machine
but it also comes with 32bit legacy mode

confused? well … looking at the cpu user manual you will have a shock
especially if you compare what you read with the Core20K's UM

Core20K is "5kc", but … it has different definitions in its AN

so, what the frog is 64bit? it's not clear when they talk about
pointer, and data, sometime p_uint64_t is NOT a 64bit pointer
(especially in legacy 32bit mode) so, why they call it _64_t ?
not clear at all  :palm: :palm: :palm:

It's a bit shocking how much code breaks when sizeof (long*) != sizeof(long)...

yes, an example is the Atlas board  :palm: :palm: :palm:
it accepts both the cpu modules, 32bit and 64bit
but you can't recompile the same examples without having to deal a lot of messes

actually you have two branches, the same code forked into two branches
because of messes with sizeof (long*) != sizeof(long)
 
long* is 64 bit with "5kc" (but it can also be 32bit if you use the legacy mode)
long* is 32bit with "4kc"

computer science, feelings of pity and sorrow for someone else's misfortune  :D
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 444
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #126 on: November 02, 2016, 10:06:39 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.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 921
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: "Stop Teaching C" - Kate Gregory
« Reply #127 on: November 02, 2016, 10:12:50 am »
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:
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #128 on: November 02, 2016, 10:14:10 am »
That's a valid observation, but it raises two important questions:
  • why do people (plural) use the "wrong" language for the problem
  • what is the domain for which there are no better languages

good question, I have no answer

concerning being the wrong language, or the right language
that is the reason why I am developing my own language

mainly because I am tired to have to deal with gcc
but I am also tired to have to deal with C itself
but it's pure hobby for my own research (=pleasure)

I mean, I am obliged to use C/C++ for my job  :-//
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10236
  • Country: gb
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #129 on: November 02, 2016, 10:19:40 am »
that is the reason why I am developing my own language

but it's pure hobby for my own research (=pleasure)

The language is, of course, the easy bit. Thereafter comes the tools, libraries, documentation, staff training... The tools and staff training are very siginificant issues with domain specific languages (DSLs).

But "because I want to have fun doing it" is a perfect, sufficient reason :)
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
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #130 on: November 02, 2016, 10:22:12 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...

I am currently mostly using the TCC compiler (http://bellard.org/tcc/ ) - the entire compiler is well under 300kB. I have it on a USB stick which I can plug into any PC I have handy and scratch out some ideas, compile in seconds and do stuff with zero fuss, rather than multi-MB downloads.

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

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #131 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: 444
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #132 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: 10236
  • Country: gb
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #133 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: 1793
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #134 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 legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #135 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 legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #136 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: 10236
  • Country: gb
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #137 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
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9205
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #138 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.
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #139 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: 5736
  • Country: nl
Re: "Stop Teaching C" - Kate Gregory
« Reply #140 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: 1199
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #141 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: 1793
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #142 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: 444
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #143 on: November 02, 2016, 03:34:18 pm »
Or you could just use Lisp :)

(Note my username)
 

Offline AG6QR

  • Frequent Contributor
  • **
  • Posts: 810
  • Country: us
    • AG6QR Blog
Re: "Stop Teaching C" - Kate Gregory
« Reply #144 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.
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9205
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #145 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.
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #146 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 legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #147 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: 1345
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #148 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 legacy

  • Super Contributor
  • ***
  • Posts: 4346
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #149 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 »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf