EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: legacy on October 30, 2016, 11:33:16 pm
-
Kate Gregory (https://www.youtube.com/watch?v=YnWhqhNdYyk)
Kate Gregory explains her reasons in this funny video :-+
-
.. and it's for sale? Or you want to swap it for a tin of striped paint? :-DD
-
Maybe Legacy figured out tggzzz isn't browsing this section and wanted to hide this lecture :popcorn:
IMHO this thread should be moved though and I think the lecture has some very valid points on how to use C++ to create robust programs and leave the bad things of C out.
-
Yes. Move it. This is the wrong place.
As for the content - I must applaud it wholeheartedly.
Teaching new people the old ways - and then having to un-learn a lot of that to be able to learn the better way of doing things is demonstrably idiotic - but it happens through laziness and complacency... and, all too often, through the lack of support by the establishment to retire the archaic tools they were brought up on.
There was one line near the start that I found as rather profound - and a key element of learning
"You can focus on whatever you want to focus on - whether it's "If"s or loops or something... the fact that there's a string class for them is a minor miracle to those of us who started learning in the 80's. It's not a minor miracle to the people you are teaching today - it's just how the world is."
This is why the kids of today grow up using the technology as they do. They don't need to understand the history; they don't need to understand the engineering to get to make the technology do something useful - and they can get pretty advanced in the utilisation without it. Certainly, there will be a point where some individuals will take things further and some of this obscure information may be necessary, but not for 80% of those who want to get into it - at least not in the first day or two!
-
Yes. Move it. This is the wrong place.
As for the content - I must applaud it wholeheartedly.
Teaching new people the old ways - and then having to un-learn a lot of that to be able to learn the better way of doing things is demonstrably idiotic - but it happens through laziness and complacency... and, all too often, through the lack of support by the establishment to retire the archaic tools they were brought up on.
In some cases a one trick pony is better than a jack of all trades. But not in most.
Eventually people gravitate to sowemewhere in between. A few tricks pony or a jack of most trades , master of some.
Deciding what should be considered for retirement as archaic, would make a great PhD thesis, getting a concensus and applying it in real life would be a different story.
Most of the annoying/long running/recurring threads "here" are mostly because of lack of basic fundamental "archaic" knowledge or skills.
-
The crux of the story can be summarised into one short paragraph, as it is in most C++ books, and easily undersood...
It takes a c++ devotee to drag it out to an hour, not unlike a lot of c++ code >:D :box:
-
Yes. Move it. This is the wrong place.
As for the content - I must applaud it wholeheartedly.
Teaching new people the old ways - and then having to un-learn a lot of that to be able to learn the better way of doing things is demonstrably idiotic - but it happens through laziness and complacency... and, all too often, through the lack of support by the establishment to retire the archaic tools they were brought up on.
In some cases a one trick pony is better than a jack of all trades. But not in most.
Eventually people gravitate to sowemewhere in between. A few tricks pony or a jack of most trades , master of some.
Deciding what should be considered for retirement as archaic, would make a great PhD thesis, getting a concensus and applying it in real life would be a different story.
Most of the annoying/long running/recurring threads "here" are mostly because of lack of basic fundamental "archaic" knowledge or skills.
Fun Fact: Most people quote the "Jack of All Trades, Master of None" part of the saying, but invariably leave out the ending...
"Jack of All Trades, Master of None, but surely better than a Master of Some."
-
i dont read it but i kinda agree with the topic. reusable functions "only" procedure as in C is obsolete. what we need is reusable object and of course still reusable functions. i cannot distinguish a pure C code since when i learnt C/C++, C++ was already there, so terms like "extern C" is pure nonsense to me. they should teach C++ first, and then if necessary C just for additional knowledge, or limited resources platform like embedded mcu.
-
they should teach C++ first, and then if necessary C just for additional knowledge, or limited resources platform like embedded mcu.
I think Kate Gregory might agree with you.
-
they should teach C++ first, and then if necessary C just for additional knowledge, or limited resources platform like embedded mcu.
I think Kate Gregory might agree with you.
btw i think learning C++ is also learning C at the same time, its just C is subset of C++, and C++ is superset of C. so when we learn C++, all is not lost in C, except some subtleties specific to C calling convention important when you want to interface with older/external codes/binaries.
-
Fun Fact: Most people quote the "Jack of All Trades, Master of None" part of the saying, but invariably leave out the ending...
"Jack of All Trades, Master of None, but surely better than a Master of Some."
why people ruling out the possibility of "Jack of All Trades, Master of Everything"? dont tell me what i cant do! :P
extern C tells the linker to find library in C calling convention, which is standardized.
yeah i mean if you are building your app from scratch, there is no reason for you to make an archaic convention for new functions anymore. hence there should be no need for "extern C". except for some specific, diminishing and subjected to extinction reasons mentioned above.
-
Fun Fact: Most people quote the "Jack of All Trades, Master of None" part of the saying, but invariably leave out the ending...
"Jack of All Trades, Master of None, but surely better than a Master of Some."
why people ruling out the possibility of "Jack of All Trades, Master of Everything" dont tell me what i cant do! :P
Anarchy!!! How can quarterly earnings be possibly predicted when too many people have this kind of attitude ? ;)
-
Fun Fact: Most people quote the "Jack of All Trades, Master of None" part of the saying, but invariably leave out the ending...
"Jack of All Trades, Master of None, but surely better than a Master of Some."
why people ruling out the possibility of "Jack of All Trades, Master of Everything" dont tell me what i cant do! :P
Anarchy!!! How can quarterly earnings be possibly predicted when too many people have this kind of attitude ? ;)
i'm not sure what you mean, but what i understand is why people who spend to much things on a particular timeframe can be the same as a person who spend on one particular thing on that same particular time frame? right? well my answer is because that "speciallized" person who spent on one particular thing to become a master could waste alot of time in the process in clubbing, beering and partying, the jack of all trades could be not.
Finally, I have to include a several MB runtime library for my C++ programs, while many C compilers depend on no DLL files except for msvcrt.dll and common Win32 dll files.
mee too, but its (calling convention) handled by macro nowadays, and i will avoid nasty call like passing the whole class to a dll with hope that the pointer who take it whatever data type it is, will point to the right location, because i'm aware of runtime virtual table.
-
"C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C."
http://harmful.cat-v.org/software/c++/linus (http://harmful.cat-v.org/software/c++/linus)
From my personal experience, I tend to agree with this.
I want to believe that there are C++ programmers who really know what they are doing.
I guess I just haven't met them...
-
"C++ is a horrible language."
here we go again :palm:
-
C and C++ both have their own problems. Neither is superior to the other. Lisp sucks. ADA sucks. Python sucks. Go sucks. D sucks. This is 50 years of computer science turd shuffling.
We need a new language that reaches down to the hardware and up to the application with some fresh ideas.
But until then everyone needs to STFU with the whining about C and build things with whatever tools you have.
-
Maybe Legacy figured out tggzzz isn't browsing this section and wanted to hide this lecture :popcorn:
... which would be mistaken, of course.
I'm certainly not going to waste an hour of my remaining life watching the whole video, but it seems to me she is saying that when teaching beginners (inc 12y year olds!) to use the "high-level" abstractions in C++, you shouldn't teach C first. That seems pretty sensible.
But most people have figured that if you want to teach "high level" abstractions to beginners in a way they can use them to earn money, there are much better languages to use.
I didn't see (but quite probably missed it in my quick skim), how to teach what people should do when something doesn't work as expected, e.g. a non-standard library or the compiler. The suggestion to use the debugger is, um, optimistic since C++ data in memory is untyped: when you most need a debugger, it can't accurately tell you what's there, let alone how it got there.
-
tgzzz - spot on. I rarely use a debugger and only in early dev to debug test cases. It's a crutch that isn't there when you have to take the biggest falls. Most things I get handed are steaming core dumps with no debug symbols. You need to know how to fight these.
I'd rather people started at the bottom and got an idea of assembly and how the CPU works at least roughly, then looked at slightly higher level languages (C), then looked at high level languages (C#/Java) if you need that sort of thing.
As for C vs C++, every place I'd use C++ I could use either Java or plain old C and tend to choose them respectively. C++ lumbers me with abstractions that are historically poorly conceived or memory heavy so I either don't use them and just use C or do use them and might as well use Java and get some higher level OO support. C++ sits in a weird void in the middle full of type, cast, structure and object weirdness.
-
I'm a prolific user of valgrind. Finds all sorts of nasties like use after frees as well.
I wrote my own data type library in C about 15 years ago as well that is quite good in these circumstances. Firstly it is heavily splattered with assert macros to force the fail fast methodology. Secondly, it gives you a to_graphviz() function for each fundamental type that will puke a graphviz file to stderr. Then a shell script that picks these out with cut marks, drops them in tmp and then renders the graphviz when it hits it and throws it in an image viewer. You can step through a program (usually with getc(), no debugger) and see the data structure changes graphically then.
I may tidy it up and stick it on github one day.
-
As for C vs C++, every place I'd use C++ I could use either Java or plain old C and tend to choose them respectively. C++ lumbers me with abstractions that are historically poorly conceived or memory heavy so I either don't use them and just use C or do use them and might as well use Java and get some higher level OO support. C++ sits in a weird void in the middle full of type, cast, structure and object weirdness.
Yes indeed. I'm reminded, w.r.t. high level abstractions, that C++'s predecessors Smalltalk and Objective-C are an improvement on C++.
C++'s designers chose to take the attitude that "we don't know what's best, so we'll punt difficult decisions to the ordinary developers". The predictable consequence is a range of implementation decisions that significantly reduces the chances that one library/implementation will play nicely with another.
One of the interesting phenomena when Java was introduced was that the papers on it and discussions about it frequently mentioned hard-won experience from other languages. In contrast C++ only mentioned C++ and C, and it was clear that many authors had a very narrow, blinkered view of the world. It is not surprising that they slowly reinvented concepts, poorly.
C has the conceptual integrity of staying close to the silicon, but even then the computer science bods have added a lot of ill-fitting cruft. (Is it possible to "cast away constness" now?)
-
Although I learnt C before C++ existed, i.e. I've been programming for a long time, I'm only a very casual programmer and know nothing of the software industry.
With that in mind, my question is:
Given all of the higher (than C++) level languages doing the rounds on all the major OS's and the reluctance to fully embrace C++ in the embedded world, is C++ jostling for somewhere to sit or does it have a dominant field somewhere?
-
Although I learnt C before C++ existed, i.e. I've been programming for a long time, I'm only a very casual programmer and know nothing of the software industry.
With that in mind, my question is:
Given all of the higher (than C++) level languages doing the rounds on all the major OS's and the reluctance to fully embrace C++ in the embedded world, is C++ jostling for somewhere to sit or does it have a dominant field somewhere?
C++ is pretty much the glue underneath most of our non-unix style computing i.e. windows and desktop applications. It has some applications in the server space such as SQL Server etc. Google also seem to use it for a lot of their stuff although they saw fit to start funding their own language (Go) that fits the same niche as it's expensive to build software in.
I see it occasionally in the finance sector, but it's dying rapidly. Managed languages (Java and C#) is where it's at with some Python creeping in and some people in shorts with macbooks writing Clojure or ruby but we have to rewrite all their shit in Java after they've gone anyway...
As for C vs C++, every place I'd use C++ I could use either Java or plain old C and tend to choose them respectively. C++ lumbers me with abstractions that are historically poorly conceived or memory heavy so I either don't use them and just use C or do use them and might as well use Java and get some higher level OO support. C++ sits in a weird void in the middle full of type, cast, structure and object weirdness.
Yes indeed. I'm reminded, w.r.t. high level abstractions, that C++'s predecessors Smalltalk and Objective-C are an improvement on C++.
C++'s designers chose to take the attitude that "we don't know what's best, so we'll punt difficult decisions to the ordinary developers". The predictable consequence is a range of implementation decisions that significantly reduces the chances that one library/implementation will play nicely with another.
One of the interesting phenomena when Java was introduced was that the papers on it and discussions about it frequently mentioned hard-won experience from other languages. In contrast C++ only mentioned C++ and C, and it was clear that many authors had a very narrow, blinkered view of the world. It is not surprising that they slowly reinvented concepts, poorly.
C has the conceptual integrity of staying close to the silicon, but even then the computer science bods have added a lot of ill-fitting cruft. (Is it possible to "cast away constness" now?)
Couldn't agree more. I keep receiving tangles of boost and stl to this day that proves that point. I can usually rewrite the whole damn thing in Java from scratch including the test suite before I've even untangled the mess even as a seasoned C++ wrangler. And then there's sticky tape like cmake and the like that just never work properly.
Anyway I'm going to stop ranting now and go and make some money :)
-
Although I learnt C before C++ existed, i.e. I've been programming for a long time, I'm only a very casual programmer and know nothing of the software industry.
With that in mind, my question is:
Given all of the higher (than C++) level languages doing the rounds on all the major OS's and the reluctance to fully embrace C++ in the embedded world, is C++ jostling for somewhere to sit or does it have a dominant field somewhere?
Java, C and C++ are the three major programming languages.
http://www.tiobe.com/tiobe-index/ (http://www.tiobe.com/tiobe-index/)
-
I see [C++] occasionally in the finance sector, but it's dying rapidly. Managed languages (Java and C#) is where it's at with some Python creeping in and some people in shorts with macbooks writing Clojure or ruby but we have to rewrite all their shit in Java after they've gone anyway...
Snort :)
Interestingly, some soft-realtime Java financial applications are very adept at avoiding GC pauses and maintaining high throughput - which is usually claimed to be an advantage for C++. Some telecom applications are the same.
OTOH if hard-realtime behaviour is required, then most of C++'s "advantageous facilities" have to be avoided, and it is necessary to write in a subset of C.
-
Indeed. In fact that's how the Windows kernel looks. It's C++ but it's not.
Erlang is the other option in this space. Now that's a platform :)
-
There is one good reason why C tends to be taught first and only later C++ (if ever or as an elective). C is usually part of the first introductory programming courses, where the students need to learn some basic algorithmic thinking first, with many having never programmed before. While C is far from an ideal language for that, the idea is, especially in engineering and not CS oriented curricula, that the student is given a tool they can use to solve real world (as opposed to toy) problems right away.
The CS students will have opportunities to learn other languages than their Python or Scheme or whatever is used in the 1st semester programming course later. For the engineering students these courses could be the only formal exposure to programming they will get during their study, that's why the language of choice is often C.
C++ in this context would be unnecessarily complex - I can't talk about OOP or metaprogramming or iterators to people who don't have a clue what a loop is or how to represent data using variables yet. You could certainly do this using C++ syntax as well, but then there would be a lot of things you would need to handwave away as something the students should take for granted and not focus on just yet (e.g. C++ strings or STL vectors and such). That's a bad thing pedagogically, because such "black magic" will reliably confuse the students. The reasons for the choice are really not technical but pedagogical in this case. (been there, done that, having taught undergraduate programming courses).
On the other hand, where the students know to program already because they are moving from e.g. Java, C# or something else, then yes, start with C++ right away. At that point the foundations should be fairly solid already. I believe that that is the situation the video is assuming.
BTW, someone said above that C++ is superset of C - it isn't. At least not a proper superset. There is plenty of perfectly valid mainstream (no obscure tricks) C code that will not compile using C++ compiler. For example C99 style struct initialization doesn't work in C++, there are more reserved words in C++ than in C (new, delete, template, auto has different meaning, etc.)
-
So should I be learning C++ instead of C for AVR microcontrollers?
-
ups, I had two tabs in my browser
and I filled the topic in the wrong one
thanks for the fix :-+ :-+ :-+
-
I like a few things about C++
operators overloading
the language is more typed
it allows passing arguments by reference
string_t is actually a string type
exceptions (even if .. well there are a lot of problem, but the idea is good)
iterators
RAII
scopes
for my own learning curve, I followed this approach
- step0: Accelerated C++ (book)
- step1: Beyond the Standard Library (book)
- step2: RAII (tutorial)
- step3: STL (tutorial)
-
With that in mind, my question is:
Given all of the higher (than C++) level languages doing the rounds on all the major OS's and the reluctance to fully embrace C++ in the embedded world, is C++ jostling for somewhere to sit or does it have a dominant field somewhere?
There's no problem with C++ in the embedded world. Much embedded programming is simply too simple to warrant doing a proper design that would take advantage to C++, but you can and I certainly have many times.
I do question the idea of teaching C++ as it's own language, distinct from C. Yes, you can do that, but it is frankly not a great language. There are better languages, depending on what you're doing, that are probably better fits for the kind of programming she wants to teach. The only reason C++ is popular is that you can use C++ kinds of things when you want to, and C kinds of things when you want to. If someone snapped their fingers and suddenly removed all of the C kinds of things from C++, C++ would die overnight.
So while the intent of the presentation is good, I think it's a bit counterproductive. Without C, there is no C++. We'd all just move over to something like D, or C#. But I guess when you have to teach a 5 day course, which is pretty ridiculous IMHO and the root of the problem, you have to make strange decisions.
-
So should I be learning C++ instead of C for AVR microcontrollers?
sure, the alternative is C, and then "Accelerated C++"
this book covers the difference from C to C++
it shouldn't be boring, I was not bored :-+
-
So should I be learning C++ instead of C for AVR microcontrollers?
That depends on:
- how you want to express your solution, i.e. what abstractions you will employ
- available RAM/ROM
- mandatory run-time behaviour
- externally imposed standards, e.g. MISRA
- what libraries you will use
- what tools are known by you and any local guru
- how long before your solution is required
My personal preference is to stick with C, but that can be overriden by any of the above considerations.
Be aware that C++ has a steeper learning curve than C, it punts many design choices to the developer, and there are more pitfalls than with C. Read learn and inwardly digest some of the pitfalls in the FQA http://yosefk.com/c++fqa/ (http://yosefk.com/c++fqa/)
-
Some of the perceptions that discourage the use of C++
in embedded systems are:
C++ is slow and C++ produces bloated machine code
and Objects are large and Virtual functions are slow
and C++ isn’t ROMable and Class libraries make large binaries
and Abstraction leads to inefficiency
and most of these ideas are wrong :D
-
I do question the idea of teaching C++ as it's own language, distinct from C. Yes, you can do that, but it is frankly not a great language. There are better languages, depending on what you're doing, that are probably better fits for the kind of programming she wants to teach. The only reason C++ is popular is that you can use C++ kinds of things when you want to, and C kinds of things when you want to. If someone snapped their fingers and suddenly removed all of the C kinds of things from C++, C++ would die overnight.
That's pretty sane.
So while the intent of the presentation is good, I think it's a bit counterproductive. Without C, there is no C++. We'd all just move over to something like D, or C#.
Don't forget that C# is, to all intents and purposes, Java with a different runtime.
-
That depends on:
…
perhaps I can add a new point:
has anyone bought the license for the C++ compiler :D ?
in my case: emmm VisualDSP++ comes with a license for C
but there is no C++KEY cardboard in the box on my desk
therefore trapped, no escape way :-DD
-
I can't talk about OOP or metaprogramming or iterators to people who don't have a clue what a loop is or how to represent data using variables yet.
I can, and have, with good success. The prerequisite is that the student can think about their problem in an abstract way, without being obsessed with a particular syntax and semantics. That's a valuable start, because then they will have a clue that they need to choose an appropriate language in which to express their problem. Good luck expressing an FSM in Prolog, or a forward/backward chaining algorithm in a matrix-based language, etc, etc, etc!
On the other hand, where the students know to program already because they are moving from e.g. Java, C# or something else, then yes, start with C++ right away. At that point the foundations should be fairly solid already. I believe that that is the situation the video is assuming.
Why bother introducing them to another language trying to do OOP (and failing to do it well), when there are so many completely different domains out there? If you want to get the students into the deeply embedded domain, use C or ADA.
-
what I really like from the Kate's talk is what she has underlined:
C++ is fundamentally different than C, everything that is valid C is valid C++
but C++ is a very different language and one needs to learn how to program in C++
and not C, to effectively use *the language* in any situation
in a nutshell: in C++, you need to program object-oriented, not procedurally
and not a hybrid of the two (big classes with lots of functions … Arduino way?)
well said, Saint Kate immediately :D
-
Don't forget that C# is, to all intents and purposes, Java with a different runtime.
Well, I'll have to respectfully disagree there. There's a good deal of difference between Java and C#, though I know what you're trying to say. And I've always hated Java, BTW. Really, though, the natural successor to C and C++ is D. It really is an excellent systems language, and is very pragmatic in it's approach.
C++, in it's infancy and before STL, was a simple language and more or less an extension of C. Despite that, it was still notoriously difficult to write a compiler for it. I remember I had all sorts of problems getting templates to work if you went too far off the reservation and tried something clever. That right there should have been a sign that something was conceptually wrong.
But that's how I like C++. It's an excellent extension to the C language. But it didn't stop there. It's turned into this whacky, steam-punk like contraption, with random pipes and valves tacked on all over the place, lumbering, belching steam and black smoke, and there's no end in sight for what else might get tacked on.
No one actually even uses the entire language, or even close to it. I'm not talking about all of the libraries. I'm talking about just the basic language features. People pick the handful of things they like, and that's all they use. You go somewhere else, and they use different things. Two C++ programs written by two different groups that do EXACTLY the same thing can written so differently that an expert C++ programmer might understand one perfectly well, but have significant trouble understanding the other. Each group will have their arbitrary rules: we use THIS, we don't use THAT. It's kind of ridiculous. Streams are a perfect example.
D is completely different. It's very simple, straightforward and easy to understand. I don't mean that it's like BASIC. It's a very rich language, but it's more like a C++ that's been designed from the ground up to be a cohesive language that makes sense. C++ is a nightmarish mish-mosh of almost academic and "safe" OOP concepts, combined with coiled cobras ready to strike, and in between is an incomprehensible labyrinth of strange notation and obscure behavior. It's like someone took 2 or 3 completely different and incompatible language, tossed them in a blender and said, "Screw it...let the programmers figure it out."
-
The thing that makes C difficult is the need to grasp basic computer architecture. Pointers are basic to any implementation even behind the scenes in C++ programs.
Learning C teaches needed basics.
-
The video was pretty good! I went looking for her books and other than one on parallel programming using a GPU, they are all OLD. Like 2003 old. Bummer! She wants to use C++14 but has yet to write anything about it.
In the back of my mind I had wanted to see a book using her concepts just in case I decided to look at C++, again. I went to the web site but, alas, their membership fees are a little rich for me.
-
The thing that makes C difficult is the need to grasp basic computer architecture. Pointers are basic to any implementation even behind the scenes in C++ programs.
Learning C teaches needed basics.
Over the last 20 years or so, there has been a move away from understanding hardware for anyone not involved with embedded or system programming. Memory is gigantic, disk space is unlimited, speed is blazing so why spend any time worrying about the details? Write code that fills the machine and wait for a bigger machine! Keeps everybody busy...
I like simple languages! When people start talking about the features of C++, I am lost. I like C and I like FORTRAN. I also like the expressive power of Python and I think PL/I was ahead of its time. Introduced today, I could see PL/I taking off. Java and C++ are just not languages that interest me. They just don't fit in my little corner of the sandbox. For dealing with data structures, I really liked Pascal.
-
Bummer! She wants to use C++14 but has yet to write anything about it
well, I will draw and list any saint immediately upon request :D
(kidding, my humor)
-
I can, and have, with good success. The prerequisite is that the student can think about their problem in an abstract way, without being obsessed with a particular syntax and semantics.
Which is exactly the point - many first year students can't do that yet, having never encountered neither programming nor abstract problem descriptions before.
Heck, high schools don't teach hands-on math or physics anymore, they "only talk about it" for the sake of making it "accessible" to everyone, because it has been perceived as "too difficult" by the government experts (Denmark, the answer I have received from high school teachers when I was wondering how come that the students don't know what a fraction is and don't understand basic symbolic notation - dead serious, not joking here!).
So this stuff is not something you can take for granted and you must start from the real basics. The time when kids were spending their afternoons and evenings hacking in Basic on their 8bitters and Amigas are long gone. The students I have had all had expensive MacBooks and similar, but beyond browsing web, pirating movies, watching porn and chatting on Facebook they didn't know at all how to use them. I have even met a guy who was copying files by opening them in Word, then copy & pasting the content into a new document and saving it under a different name. Another one kept the protective film on the display of his new laptop for several months, squinting around the creases when he couldn't see the text properly :palm:
So that is the "material" these courses have to work with.
That's a valuable start, because then they will have a clue that they need to choose an appropriate language in which to express their problem. Good luck expressing an FSM in Prolog, or a forward/backward chaining algorithm in a matrix-based language, etc, etc, etc!
Why? FSM in Prolog is perfectly fine:
http://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node5.html (http://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node5.html)
Not that I would teach introduction to programming with Prolog, though ...
Not sure what you mean by "matrix-based", something like R or Matlab? I don't see why such algorithm would be difficult in these. Befunge (https://en.wikipedia.org/wiki/Befunge (https://en.wikipedia.org/wiki/Befunge)) on the other hand ...
Why bother introducing them to another language trying to do OOP (and failing to do it well), when there are so many completely different domains out there? If you want to get the students into the deeply embedded domain, use C or ADA.
Because not all curicula are about (deeply) embedded programming? The uni I was at was teaching basics of programming even to future chemistry and mechanical engineers that would go on to design oil rigs and refineries, for example. They may never develop software for sale during their careers but they may have to build a simulation of something, to analyze some data or to build a plugin for that Matlab they are most likely going to be using. So knowing at least the basics is going to be useful for them.
But as I have said - C++ is often not taught or it is an elective - in that case it is not my business to question the motivation of the students why did they choose the course. Perhaps they want to simply increase their value on the job market - there are certainly more jobs for C/C++ programmers than for ADA ones, for example.
-
So, I've been taking some python classes. Interesting stuff; just what I need for dealing with .xml files (for example.)
But as an old C/asm OS/embedded programmer, there are definitely some "disturbing" aspects (common to a a LOT of these modern languages that are being pushed in CS):
1) All containers are dynamically allocated and resizeable (in python, this includes integers!)
2) algorithmic elegance and theoretical performance beats implementation quality.
2a) If performance is A*f(n), only the magnitude of f(n) matters (ie O(n**2))
2b) recursion is an elegant and desirable implementation tool.
3) performance of language elements is not considered.
4) size of runtime environment is not considered.
-
I do a fair bit of work with python. It's slightly horrible to merge, slow as anything and the packaging story is horrible. Great for one shot quick projects, prototypes and testing ideas etc. I have a script running on a Pi Zero that hangs off the back of my Xbox for power that is headless and runs a python script every ten minutes scans gumtree for things before anyone else gets them :)
Scored me a Marconi 2019A for £10 :)
-
@westfw
as gentoo user I hate python :D
emerge is written in python along to a lot of tools
and python is always the first reason of my troubles
(especially under catalyst when I "cook" new stages
or when I emerge --sync an old stage4)
ok, it's not due to the language, which is fine, elegant, etc
it's just the tool, implementation and handling matter
the behavior of python v2.* is not exactly compatible with v3.*
and this may cause (and practically it does) troubles when you upgrade
I mean the code is not exactly portable "as is", it needs some work :-//
-
has anyone bought the license for the C++ compiler :D ?
One of the best C/C++ compilers is available for free. Why on earth would somebody pay for it (apart from donations)?
-
Don't forget that C# is, to all intents and purposes, Java with a different runtime.
Well, I'll have to respectfully disagree there. There's a good deal of difference between Java and C#, though I know what you're trying to say. And I've always hated Java, BTW. Really, though, the natural successor to C and C++ is D. It really is an excellent systems language, and is very pragmatic in it's approach.
A few months before C# was released, Anders Hejlsberg (the C# designer) gave a talk on C# at my workplace. After listening to what he had to say, we said we thought it sounded like Java with a different philosophy to the runtime environment, and asked him if that was the case. He didn't disagree, so we presume we did understand :)
The key difference is that C# does static optimisation based on what the compiler guesses the code will do at runtime, whereas HotSpot measures what the code is actually doing and optimises what is actually occurring. Both approaches are valid, of course, and are advantageous in different situations.
C++, in it's infancy and before STL, was a simple language and more or less an extension of C. Despite that, it was still notoriously difficult to write a compiler for it. I remember I had all sorts of problems getting templates to work if you went too far off the reservation and tried something clever. That right there should have been a sign that something was conceptually wrong.
There was worse: it was discovered the c++ template was Turing-complete, but the design committee didn't believe it until someone rubbed their noses in it by causing the compiler to emit the sequence of prime numbers during (infinite) compilation! That's from https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP (https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP) with my emphasis added. The original is at http://www.erwin-unruh.de/primorig.html (http://www.erwin-unruh.de/primorig.html) Note: not designed, but discovered - and that's exactly what happened.
Personally I prefer my languages to be designed, not discovered!
But that's how I like C++. It's an excellent extension to the C language. But it didn't stop there. It's turned into this whacky, steam-punk like contraption, with random pipes and valves tacked on all over the place, lumbering, belching steam and black smoke, and there's no end in sight for what else might get tacked on.
Snort :) Having said that, Java is showing similar behaviour :(
No one actually even uses the entire language, or even close to it. I'm not talking about all of the libraries. I'm talking about just the basic language features. People pick the handful of things they like, and that's all they use. You go somewhere else, and they use different things. Two C++ programs written by two different groups that do EXACTLY the same thing can written so differently that an expert C++ programmer might understand one perfectly well, but have significant trouble understanding the other. Each group will have their arbitrary rules: we use THIS, we don't use THAT. It's kind of ridiculous. Streams are a perfect example.
Just so :(
C++ is a nightmarish mish-mosh of almost academic and "safe" OOP concepts, combined with coiled cobras ready to strike, and in between is an incomprehensible labyrinth of strange notation and obscure behavior. It's like someone took 2 or 3 completely different and incompatible language, tossed them in a blender and said, "Screw it...let the programmers figure it out."
Just so. I can't comment on D, only having briefly looked at it and never used it.
-
That's a valuable start, because then they will have a clue that they need to choose an appropriate language in which to express their problem. Good luck expressing an FSM in Prolog, or a forward/backward chaining algorithm in a matrix-based language, etc, etc, etc!
Why? FSM in Prolog is perfectly fine:
http://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node5.html (http://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node5.html)
Not that I would teach introduction to programming with Prolog, though ...
Well, yes, they are both Turing complete. You can also use a hammer to insert a screw :)
Not sure what you mean by "matrix-based", something like R or Matlab? I don't see why such algorithm would be difficult in these. Befunge (https://en.wikipedia.org/wiki/Befunge (https://en.wikipedia.org/wiki/Befunge)) on the other hand ...
Yes, that kind of thing; there are many. Probably not APL, even though the characters no longer require changing the typewriter's golfball :)
Why bother introducing them to another language trying to do OOP (and failing to do it well), when there are so many completely different domains out there? If you want to get the students into the deeply embedded domain, use C or ADA.
Because not all curicula are about (deeply) embedded programming? The uni I was at was teaching basics of programming even to future chemistry and mechanical engineers that would go on to design oil rigs and refineries, for example. They may never develop software for sale during their careers but they may have to build a simulation of something, to analyze some data or to build a plugin for that Matlab they are most likely going to be using. So knowing at least the basics is going to be useful for them.
That's precisely my point!
But as I have said - C++ is often not taught or it is an elective - in that case it is not my business to question the motivation of the students why did they choose the course. Perhaps they want to simply increase their value on the job market - there are certainly more jobs for C/C++ programmers than for ADA ones, for example.
Such students should be kept away from keyboards. And yes, it is my business and duty (as an interviewer) to question their motivation :)
-
A few months before C# was released, Anders Hejlsberg (the C# designer) gave a talk on C# at my workplace. After listening to what he had to say, we said we thought it sounded like Java with a different philosophy to the runtime environment, and asked him if that was the case. He didn't disagree, so we presume we did understand :)
AFAIK C# is Java which works. I recall reading that somewhere down the line Microsoft abandoned C++, didn't manage to get people into using Visual basic, found Java to be a mess (which it is) and came up with C# as a final solution to have an alternative for C++. The rest is history.
-
there are certainly more jobs for C/C++
programmers than for ADA ones
sure, but consider the good side of the coin:
those in the circle of ADA programmers
are paid more money than those
in the circle of C/C++ programmers :D
good, ain't it?
-
if you know Prolog then you can find
a lot of job opportunities with AADL
e.g. the Stood (http://www.ellidiss.com/products/stood/) Team
yes, unbelievable but Stood is actually written in Prolog
well paid job, unfortunately it's a damn complex job
and they don't need a lot of programmers :palm:
(I know a few dudes in that team, their emails
due to Stood bugs report
I mean Stood is used in avionics for everything,
including code-design and documentation)
-
A few months before C# was released, Anders Hejlsberg (the C# designer) gave a talk on C# at my workplace. After listening to what he had to say, we said we thought it sounded like Java with a different philosophy to the runtime environment, and asked him if that was the case. He didn't disagree, so we presume we did understand :)
AFAIK C# is Java which works. I recall reading that somewhere down the line Microsoft abandoned C++, didn't manage to get people into using Visual basic, found Java to be a mess (which it is) and came up with C# as a final solution to have an alternative for C++. The rest is history.
Not quite.
MS couldn't use their usual "embrace and extend" tactic with Java, so they decided to triumphantly reinvent that particular wheel.
Unfortunately due to their strategy, they couldn't abandon C++, so they brought it inside the runtime via the "unsafe" keyword. That ensured they threw away an advantage of managed runtime environments - leaving them with the (small) overhead of a managed environment without its (major) advantage.
While the business rationale is impeccable, as an engineer I think that tradeoff is wrongheaded.
-
C is a slapped together (it was made so they could make an OS) , language for an obsolete computer architecture (PDP) , based on a lexer and parser that is so stupid it needs semicolons to figure out where a line ends ...
it's time it dies.
-
Personally I prefer my languages to be designed, not discovered!
the only thing that is designed proof is a dead stone. once you open the complexity, how do you expect it is more perfect than the source of its existence? i mean, a language that put more restriction on the users, hence more controlled parameters from inside, designed by the language architech... granted it will be easier to make it turing complete, but is it worth the cost? to the users/programmers freedom side of things?
C is a slapped together (it was made so they could make an OS) , language for an obsolete computer architecture (PDP) , based on a lexer and parser that is so stupid it needs semicolons to figure out where a line ends ...
it's time it dies.
oh you havent typed in the modern languages. the ;, at, on, in... whatever syntaxes is notoriusly overwhelming, if i use that words correctly... be careful on what you pray for..
-
C is a slapped together (it was made so they could make an OS) , language for an obsolete computer architecture (PDP) , based on a lexer and parser that is so stupid it needs semicolons to figure out where a line ends ...
it's time it dies.
Well, as many bad things as I have to say about C++ I can say good about C. I think C is darn near the perfect at doing what it was designed to do.
-
Just so. I can't comment on D, only having briefly looked at it and never used it.
Oh, you should definitely try it. The next time you have a small little utility to write, give it a try. You'll slowly find yourself using it more and more. A lot of it looks deceptively like C, but that was just for familiarity. It's what a modern language should look like.
-
ADA
I was at ARM TechCon last week, and I finally figured out why Ada (and other langauges) have no popularity in embedded...
There was this big trade show, and lots of vendors.
IAR and Greenhills were there with their C compilers (plus ARM themselves with Keil, and Atmel/etc with gcc.)
Assorted vendors offering specialized debugging tools. For C.
Assorted vendors with networking stacks: USB, Bluetooth, TCP/IP, assorted random wireless protoocols. In C.
Assorted vendors with operating systems: mBed. Micrium. MyNewt. Zephyr. All in C.
And, on the edge of the room, there was AdaCore with their Ada Compiler... All by themselves.
I didn't see any "D", and I'm not sure about C vs C++. There might have been some Java. No C#, AFAICT. After C the most "interest" was in the BBC Micro Bit, which has its own graphical programming language (for kids, you know.)
Most of the realistic alternatives to C in the embedded space are just languages. C is ... multiple industries!
-
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
-
And, on the edge of the room, there was AdaCore
with their Ada Compiler... All by themselves.
so, no chance to promote my own made language :D ?
it looks ADA-like, not yet decided how to call it
p.s.
but on Irc I have seen a lot of ADA-dudes
p.s.2
2016-11-01--13-14-37---2016-11-01--16-51-50 - emerge =sys-devel/gcc-4.1.2 - success - root
2016-11-01--18-14-10---2016-11-01--20-02-04 - emerge =sys-devel/gcc-4.9.3 - success - root
2016-11-01--20-11-57---2016-11-01--20-38-24 - emerge =dev-lang/gnat-gcc-4.1.2 - failure - root
2016-11-01--21-04-40---2016-11-02--00-34-12 - emerge =dev-lang/gnat-gcc-4.6.4 - failure - root
2016-11-02--00-53-29---2016-11-02--04-18-11 - emerge =dev-lang/gnat-gcc-4.9.3 - failure - root
it seems GNAT is having some ... difficulties (on gentoo)
Most of the realistic alternatives to C in the embedded space
are just languages. C is ... multiple industries!
exactly the point: companies have invested money
resources, effort, etc
-
Bugs
327043 : dev-lang/gnat-gcc-4.3.4 - precompiled bundled gcc is linked against old libmpfr
386661 : [portage-multilib] dev-lang/gnat-gcc: configure error for x85-abi due to gnatboot-4.4-amd64.tar.bz2
402157 : Remove dev-lang/gnat-gcc and dev-ada/asis-gcc
501178 : dev-lang/gnat-gcc-4.6.4: gnatmake always fails because it cannot find liblto_plugin.so
502444 : dev-lang/gnat-gcc version bump request
520154 : dev-lang/gnat-gcc-4.7.3 ?/gnatboot-4.6 - add HPPA support
536124 : dev-lang/gnat-gcc-4.4.7 - In file included from .../work/gcc-4.4.7/gcc/unwind-dw2.c:333: .../work/gcc-4.4.7/gcc/config/i386/linux-unwind.h:138: error: field ‘info’ has incomplete type
549546 : dev-lang/gnat-gcc-4.3.6 fails to build on ppc
554966 : dev-ada/glade-2006.0: wants dev-lang/gnat-gcc-4.2.3 which fails with "configure: error: installation or configuration problem: C compiler cannot create executables."
560286 : dev-lang/gnat-gcc-4.6.4-r1: USE Flag 'multilib' not in IUSE for dev-lang/gnat-gcc-4.6.4
561968 : dev-lang/gnat-gcc-4.5.4 fails to merge in install phase with `USE Flag 'lto' not in IUSE`
586538 : dev-lang/gnat-gcc: old lto wrapper breaks newer gcc (e.g. using -march=native)
596932 : dev-lang/gnat-gcc-4.6.4 - src_install(): /bin/sh: line 3: cd: host-x86_64-pc-linux-gnu/lto-plugin: No such file or director
the fortune algorithm (https://forums.gentoo.org/viewtopic-t-1039970.html?sid=9cfb1553d8e0ae266d46d5e8ddcd1f8d) is required in order to emerge dev-lang/gnat-gcc :-//
-
ARM TechCon
I see more bootstrappers for PowerPC
(which are also mainly used in avionics)
I believe ARM is less ADA friendly
perhaps less interests in the industry
-
AFAIK C# is Java which works.
Nope. C# works on windows. Java works everywhere.
-
It's deeper than that. Even the official ASP.net framework, official CLR, C# compiler, visual studio core and recently SQL server work on Linux and MacOS. There's even an LLVM front end that compiles C# to native. All of them are open source apart from SQL Server.
-
I've now watched the video. The title is a bit misleading - it's actually "Stop teaching C as the first step to teaching C++", and I think I mostly agree with the things she says. (particularly WRT skipping the whole "char*" "strings" that C requires.) 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. (The assembler class did that for the PDP11 portion. You'd write little programs that ran on a simulator, giving them things to work on by sticking them in memory before you started and looking at your results in memory when they finished. Yuck.) (although I also really dislike C++ "<<" streams.)
(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.)
-
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.
Doing the retrograde learning process makes just as much sense as teaching water engineers how to build aquaducts ... and then tell them to forget about all that as you try to teach them about using pipes. They're still holding to constrained thinking of open waterways and gravity - instead of the freedom from those constraints and the importance of pressures.
Remember, this is for beginners on their way to C++.
Once you've got there, then - by all means - let them learn more advanced stuff - like the issues involved in developing embedded systems ... and how to use the primitive features of C.
-
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!
-
what I really like from the Kate's talk is what she has underlined:
C++ is fundamentally different than C, everything that is valid C is valid C++
but C++ is a very different language and one needs to learn how to program in C++
and not C, to effectively use *the language* in any situation
i pulled the trigger. i HAVE to learn new languages, i'ts about time and i can't live with visual basic and c only so i went to the local library and took two books on c++. unfortunately those are from 1990 and 1993.
what yuo quotes was the very first chapters.
i guess 20 years of stressing it has not been enough :)?
-
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). However, if it is to skill up someone going into a C++ environment, then there's no need to look any further.
-
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
-
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.
-
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...
-
(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.
-
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!
-
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
-
(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...
-
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:
-
(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.
-
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.
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'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
-
p.s.
just for my curiosity, do you/your team use Stood for your own designs?
if yes, is it really helpful?
-
Kate Gregory's Blog (http://www.gregcons.com/kateblog/) looks very interesting :-+
-
Kate says Yes on Lambdas (http://www.drdobbs.com/cpp/lambdas-in-c11/240168241) in C++
and she promotes the use,
but I haven't yet understood (http://stackoverflow.com/questions/7627098/what-is-a-lambda-expression-in-c11) if
I really like this C++11 feature :-//
-
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 ...
-
.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.
-
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
-
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.
-
Kate says Yes on Lambdas (http://www.drdobbs.com/cpp/lambdas-in-c11/240168241) in C++
and she promotes the use,
but I haven't yet understood (http://stackoverflow.com/questions/7627098/what-is-a-lambda-expression-in-c11) 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.
-
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.
-
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.
-
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
-
ls /idp.do/mysrc/lib/
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 }
-
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++?
-
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
-
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.
In large projects, developed by large, distributed teams, there's often a need to control the distribution of function signatures. I worked on a commercial product which included libraries distributed to customers. It was divided into a number of components. We had four levels of function distributions:
- Public -- documented to our customers and available for them to call
- Intracomponent -- sort of "internally public", meaning different components that we developed in our company could share Intracomponent functions, and they were somewhat documented internally among ourselves, but we didn't allow customers to call them.
- Within a single component -- shared inside a single component only
- Within a single source file
Why the need for the different levels of publishing and sharing functions? It's a form of encapsulation. By limiting the distribution of a component's internal functions, those internals could be freely changed as the software evolved, without having to worry that someone had already written software that relied on a particular function signature that, in retrospect, wasn't a good one. It meant we could freely and safely put hidden internal things into functions without worrying that some customer would write software that called those functions.
We implemented this by having different header files in different directories, and sharing those directories appropriately. Not all projects would need this particular set of levels of sharing, but the header file concept makes it easy to implement whatever level of sharing is appropriate for your project.
I do agree that, in general, it's bad to have something expressed twice when it can be expressed once. Header files express a function's signature twice, once in the header file and once in the function definition. Having the function signatures expressed only one place would be preferable. But header files can express another thing about the function: They can express how widely you intend to share the function. If you do away with header files, you would need to provide another mechanism to express this.
-
I do agree that, in general
it's bad to have something expressed twice
when it can be expressed once.
Header files express a function's signature twice,
once in the header file and once in the function definition.
mmm, in my case you write the body
and the compiler will automatically build the interface
therefore you write boolean_t is_foo() { ... }
and it will fill "boolean_t is_foo()" in the module.interface
which is included in module.h
it's saving a lot of troubles here, and it's damn productive
the downside of this approac is that if change the interface
e.g. boolean_t is_foo( uint32_t magic ) you are breaking
the compatibility of your library, therefore I have implemented
a mechanism which refuses to accept the new commit
until you have turned it into a branch and changed the
module name or - at least - increased the revision
it's not a definitive solution, but it works :-+
-
Have some more C++ buggery now I have a few minutes. Firstly, we'll compile a couple of hello worlds:
First the C version
#include <stdio.h>
void say_hello(char *to_whom) {
printf("Hello %s", to_whom);
}
Now the C++ version
#include <iostream>
using namespace std;
void say_hello(string to_whom) {
cout << "Hello " << to_whom << endl;
}
Compile them quickly into object files only...
[setq@shodan ~]$ g++ -c hellocpp.cpp
[setq@shodan ~]$ gcc -c hello.c
Now let's look at the symbol table in the ELF file generated by the C program:
[setq@shodan ~]$ readelf -s hello.o
Symbol table '.symtab' contains 11 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello.c
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 3
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 0 SECTION LOCAL DEFAULT 5
6: 0000000000000000 0 SECTION LOCAL DEFAULT 7
7: 0000000000000000 0 SECTION LOCAL DEFAULT 8
8: 0000000000000000 0 SECTION LOCAL DEFAULT 6
9: 0000000000000000 36 FUNC GLOBAL DEFAULT 1 say_hello
10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND printf
Yep that made sense. There's a FUNC in there called say_hello and it calls out to printf. Easy money.
Now for C++
[setq@shodan ~]$ readelf -s hellocpp.o
Symbol table '.symtab' contains 23 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS hellocpp.cpp
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 3
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 1 OBJECT LOCAL DEFAULT 4 _ZStL8__ioinit
6: 0000000000000000 0 SECTION LOCAL DEFAULT 5
7: 0000000000000039 61 FUNC LOCAL DEFAULT 1 _Z41__static_initializati
8: 0000000000000076 21 FUNC LOCAL DEFAULT 1 _GLOBAL__sub_I__Z9say_hel
9: 0000000000000000 0 SECTION LOCAL DEFAULT 6
10: 0000000000000000 0 SECTION LOCAL DEFAULT 9
11: 0000000000000000 0 SECTION LOCAL DEFAULT 10
12: 0000000000000000 0 SECTION LOCAL DEFAULT 8
13: 0000000000000000 57 FUNC GLOBAL DEFAULT 1 _Z9say_helloSs
14: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZSt4cout
15: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZStlsISt11char_traitsIcE
16: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZStlsIcSt11char_traitsIc
17: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZSt4endlIcSt11char_trait
18: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZNSolsEPFRSoS_E
19: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZNSt8ios_base4InitC1Ev
20: 0000000000000000 0 NOTYPE GLOBAL HIDDEN UND __dso_handle
21: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZNSt8ios_base4InitD1Ev
22: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __cxa_atexit
Wow that was a really clean abstraction. Not! 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.
I'm off to go and write some PIC16 assembly now - that stuff is eye bleach programming bliss.
-
assembly now
it happens because in C++ you have
string_t, which is not just an array with '\0' at the end
it's true type, a struct, which implies methods, e.g. "<<"
a part of the machine code needs to be taken
to fetch out these details e.g. invoking the method
-
who uses tape these days ?
bad example, dude, I use tapes :D
but not as primary random access storage ! that would be fun compiling a project. waiting for the tape robot to find the tape where the file is stored , load it, fast forward / rewind to where it sits, read it , save the obj to another tape... people are now already complaining if a compile takes 5 seconds or longer ....
-
assembly now
it happens because in C++ you have
string_t, which is not just an array with '\0' at the end
it's true type, a struct, which implies methods, e.g. "<<"
a part of the machine code needs to be taken
to fetch out these details e.g. invoking the method
I know why. It just feels like ceremonial on the lines of:
https://www.youtube.com/watch?v=xOrgLj9lOwk (https://www.youtube.com/watch?v=xOrgLj9lOwk)
-
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.
multipass compilation solves parsing problem.
pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)
pass 2 : compile all standalone functions ( functions that do not call others ) into machine language. create a callable and in-line variant for each.
pass 3 : compile functions that call others. direct calls become in-line. nested calls become true calls.
repeat pass 3 until top level of hierarchy is reached.
pass 4 : map final memory allocation for all function and assign hard addresses. (essentially linking)
pass5 : spit out binary.
pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?
-
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....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
-
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.
How about the constants, type definitions, data structures etc. There is a lot more than just functions in programming.
-
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.
multipass compilation solves parsing problem.
pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)
pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?
GCC can do that just fine for many years BUT you have to be carefull with interrupt routines which aren't called from anywhere else.
Besides that there is much more to compiling C than you seem to be aware of. The first step is collecting all the header files and evaluating the pre-processor macros by the pre-processor and put everything in one file with pure C code which is then compiled by the compiler into an object file. Compiling a C program consists of: pre-processing, compiling and linking. The pre-processing stages makes it easy to re-use code by using constants defined in one place and/or include/exclude parts of code depending on variables (which can be supplied on the command line).
-
you have to be carefull with interrupt routines
which aren't called from anywhere else
in the theory the body of an isr should be at least loaded
therefore their names should compare inside an initializer
e.g.
void isr_init()
{
..
isr_set(isr_machine_exception, 0x00000100);
..
}
it's not the only way to handle isr, I find it useful
-
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.
multipass compilation solves parsing problem.
pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)
pass 2 : compile all standalone functions ( functions that do not call others ) into machine language. create a callable and in-line variant for each.
pass 3 : compile functions that call others. direct calls become in-line. nested calls become true calls.
repeat pass 3 until top level of hierarchy is reached.
pass 4 : map final memory allocation for all function and assign hard addresses. (essentially linking)
pass5 : spit out binary.
pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?
I'm not sure you're thinking this through clearly. Consider something like this:
a * b;
To do what you suggest would require looking through every tiny little bit of code to see just what the heck "a" is. Do you intend to multiply a*b, or are you declaring a pointer to something of type a? That's just one example.
I could keep going on this, but there's a reason C is the way it is, and why it hasn't really changed. More modern languages don't have ambiguities like this, or at least they're limited and easily addressed, so the compiler doesn't run into a brick wall. C is just not well suited for this sort of thing.
-
my claim is : there is no need for includes and .h files.
Correct. Just put everything in a single source file - makes the compiler's job a lot easier! ;)
-
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....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
the rocket programmer was not aware of that, so the compiler programmer is to be blamed.
-
Believe it or not, it's for machine independence. Blame the idiot programming team that depends on running the code in simulation to check for overflows and things like that. It's a failure in specification and could happen regardless of language.
-
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....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
IMHO you should always use the fixed length types (inttypes.h) and not the typical C types (char, int, long, etc) because they are defined poorly. Also check the range of floating point types to make sure you don't run into trouble. See http://stackoverflow.com/questions/752309/ensuring-c-doubles-are-64-bits (http://stackoverflow.com/questions/752309/ensuring-c-doubles-are-64-bits)
-
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 bitthat was Ada. "AdaTran", actually - badly converted Fortran.
https://vimeo.com/44792649#t=530s
Language used sounds like it was one of the least of their problems :-(
(Though I like the comment "If it had been written in C, it wouldn't have blown up.")
-
my claim is : there is no need for includes and .h files.
Correct. Just put everything in a single source file
- makes the compiler's job a lot easier! ;)
sarcasm? :-DD
-
they are defined poorly
yep, a mess
e.g.
m68k (CISC)
a long is 32bit
a short is 16bit
a char is 8bit(2)
a word is 16bit
there is no half
a long long is 64bit
MIPS (RISC)
a long is 32bit
a short is 16bit(1)
a char is 8bit(2)
a word is 32bit <------
there is also half (word), which is 16bit
a long long is 64bit <-----
(1) but sometimes with PowerPC (RISC) is 32bit
I have seen sizeof(short)=2byte, sometimes =4byte
WTF :wtf: :wtf: :wtf:
(2) some DSP by TI says that char is 16bit :-// :-// :-//
-
word and half are not *C terms*
they come from CPU manuals
like a contribute to the confusion :palm:
I believe "word" was 16bit with 68K
(which is a true 32bit machine)
because the 68000 bus was 16bit
while the R2000 bus was 32bit
therefore half (word) makes sense for MIPS
the problem is: the C language should not stay
so close to the hardware, especially if it aims
for being a portable language
it's just an example, it shows the wrong attitude
-
word and half are not *C terms*
they come from CPU manuals
like a contribute to the confusion :palm:
I believe "word" was 16bit with 68K
(which is a true 32bit machine)
because the 68000 bus was 16bit
while the R2000 bus was 32bit
therefore half (word) makes sense for MIPS
the problem is: the C language should not stay
so close to the hardware, especially if it aims
for being a portable language
it's just an example, it shows the wrong attitude
It shows that the language doesn't fit your problem you are using it for.
It doesn't really show that the language has the wrong attitude...
Take for example early PC development, with 'near pointers' and 'far pointers' and 'huge pointers'. Much to C's credit it could actually be made to work with such painful system with only a few extra key words.
The problem isn't that the language wasn't portable, it is that the programmer was unaware of the assumptions they are working under.
I am currently working on something to process audio files. It would be really easy for me to write a program that reads a WAV file on my PC, but fails on other h/w due to endian mismatch.
Do I say "Stupid language", or "Stupid hardware designer", or "Stupid me"?
I say "stupid me" - I should be doing it in something like MatLab anyway, but hey, I know C, I am lazy, and the problem looks like a nail to me. :)
-
m68k (CISC)
a long is 32bit
a short is 16bit
:
x86 (CISC):
depends on compiler settings. (actually, I'm pretty sure that's true of MIPS64 as well. Probably ARM64 too; it's at least a gcc thing.)
I think you get your choice of "longs and ptrs are 32 bits", "longs are still 32bits bit pointers are 64", "longs are 64bits but pointers are still 32bits", and "longs and ptrs are both 64bits."
It's a bit shocking how much code breaks when sizeof (long*) != sizeof(long)...
-
they are defined poorly
yep, a mess
e.g.
m68k (CISC)
a long is 32bit
a short is 16bit
a char is 8bit(2)
a word is 16bit
there is no half
a long long is 64bit
MIPS (RISC)
a long is 32bit
a short is 16bit(1)
a char is 8bit(2)
a word is 32bit <------
there is also half (word), which is 16bit
a long long is 64bit <-----
(1) but sometimes with PowerPC (RISC) is 32bit
I have seen sizeof(short)=2byte, sometimes =4byte
WTF :wtf: :wtf: :wtf:
(2) some DSP by TI says that char is 16bit :-// :-// :-//
The basic way it works is:
- int is USUALLY the word size of the machine, thought that's generally no longer true on 64 bit systems
- char is the smallest addressable unit, which is normally 8 bits, but there are a number of processors (usually DSPs) where it's larger. It's always 8 bits or more regardless, though
Beyond that, the types are defined like this:
- each type must hold some MINIMUM value. For example, a char must be able to hold at least +/-127
- each type must not be smaller than the one that came before. So for example, just looking at the minimums, it's conceivable that a short be 64 bits and an int 32 bits, but that's not allowed.
So anyhow, if it's not enough to know the minimums, then you need to use fixed width types. I agree...it's a mess.
-
In C the sizeof(char) == 1, but the char may be 8, 16, 24 bits or something else depending of the architecture. For example, in some DSPs a char is 16 bits or even 24 bits.
-
It shows that the language doesn't fit your problem you are using it for.
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
-
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
-
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.
-
Although the D language (http://dlang.org/) looks excellent, it also states it was designed for 32 bit and up (http://dlang.org/overview.html).
I can find compilers for the Windows and Linux and some ARM (https://wiki.dlang.org/Compilers#Comparison) (not an expert).
So for smaller MCU there is no support it seems.
My 2c.
Please continue with the C/C++ bashing..
:horse:
:popcorn:
-
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 :-//
-
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 :)
-
- 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/ (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.
-
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
-
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 ;)
-
- 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!
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!)
-
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.
-
separate the physical data type representation
from the logical data type definitions
sure, well written, I agree :D
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)
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
-
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 (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf) :-//
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
-
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 (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf) :-//
haven't yet understood if C++ gives some help about that
In general, no it can't, but...
(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.
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 (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 :) )
-
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.
-
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
-
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.
-
Although the D language (http://dlang.org/) looks excellent, it also states it was designed for 32 bit and up (http://dlang.org/overview.html).
I can find compilers for the Windows and Linux and some ARM (https://wiki.dlang.org/Compilers#Comparison) (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.
-
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. :)
-
Or you could just use Lisp :)
(Note my username)
-
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.
-
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.
-
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 (http://www.mikroe.com/mikropascal/arm/), for arm!
my memory is still good :D
also, there is freepascal (https://forum.pjrc.com/threads/28518-Teensy-with-Freepascal), used on Teensy and GBA
-
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 (http://wiki.freepascal.org/TARGET_Embedded) :-//
-
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.
-
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 :-//
-
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?
-
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).
-
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.
-
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!"
-
<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'.
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.
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.
-
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.
-
@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?
-
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.
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.
-
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.
-
@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
-
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.
-
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.
-
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.
-
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.
-
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.)
-
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.
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.
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.
-
... 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".
-
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 :(
-
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.
-
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.
-
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.
-
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.
-
it only supports Ubuntu at the moment
yep, the get started appears here (https://swift.org/download/#previews), and
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) ...
swift-v2.2 # file usr/bin/swift
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:
-
my x86 laptop is 32bit my laptop is x86
fixed that for you...
-
it only supports Ubuntu at the moment
yep, the get started appears here (https://swift.org/download/#previews), and
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) ...
swift-v2.2 # file usr/bin/swift
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.)
-
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
-
BTW Swift seems THE language
is it the one? good question :D
"Stop Teaching C" + "teach Swift"
(might it be? who knows …)
-
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.
-
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.
-
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.
-
Seen few minutes of the video: What a bullshit that is. Yeah. Just stop teaching anything, because it requires to learn. :palm:
-
@Marco, Brumby
the topic is mine, and I have no problem with the brain storming we are actually doing
someone can comment the video where saint Kate explained her right
someone can agree, someone can disagree
someone can explain his/her points
someone can confirm the sanctity to saint Kate ( I do )
someone can revoke the sanctity to saint Kate
someone can argue that we are still looking for a modern language ( I am still )
someone can give me some good advice helping me to design my own made language
(thanks dudes )
no problem at all
come, take a beer, a coffee, a tea (I know, British have tea-time)
( I know, Americans prefer coffee, with/without milk? )
some chocolate ("after eight") ? some biscuits? some red wine?
enjoy my emoticon :popcorn:
there is just a rule: never ever talk about GCC!
immediately permanently banned if so :-DD
-
at the end, I have chosen "Swift" because
it seems to have some legacy with C/C++
and I will follow some "Saint-Kate's points"
-
Seen few minutes of the video: What a bullshit that is. Yeah. Just stop teaching anything, because it requires to learn. :palm:
That is not the point of the video. The point is that C++ offers many ways to program smarter with less chance of errors but most teachers start with C because they think that C has basics but that is a false assumption. You really don't need to know the low level C stuff in order to create good C++ programs so don't teach/learn that if you want to get going quickly. The C stuff is just extra luggage you can do without.
-
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.
Well, that's the approach that Donald Knuth took with MIX and MMIX in "The Art Of Computer Programming". I'm not sure that physical MIX computers were around but, given FPGAs, it would be trivial to built the 64 bit MMIX computer. At his web site, Dr. Knuth reiterates why he continues to discuss low level machine instructions and how to use them to deal with complex structures:
http://www-cs-faculty.stanford.edu/~knuth/mmix.html (http://www-cs-faculty.stanford.edu/~knuth/mmix.html)
I like to think of C as one step up from assembly language. C++ and Java are several flights up. Perhaps C++ should have been named something else.
-
Seen few minutes of the video: What a bullshit that is. Yeah. Just stop teaching anything, because it requires to learn. :palm:
That is not the point of the video. The point is that C++ offers many ways to program smarter with less chance of errors but most teachers start with C because they think that C has basics but that is a false assumption. You really don't need to know the low level C stuff in order to create good C++ programs so don't teach/learn that if you want to get going quickly. The C stuff is just extra luggage you can do without.
There is no such "without luggage". Either you will carry the luggage and produce some nice code, or you will support bloatware bullscheisse and the CPU will take care of your luggage. ;D
Modern days dictate to teach only high level programming languages - but I am fed up with the bullmerde software the world is now full of, will be glad to see some skilled low level programmers :-+
To sum up: Everyone shall learn what he or she is interested in. :-/O
-
I am disagree with several topics this video.
First point, I have never been a fan of the language C and i have always found very weaknessed(my opinion bad design) that i gave many troubles when i performed several projects .
I don't know as is programming with C++ because i never used , but i have experienced with other programming language that are oriented to objected (.NET .JAVA) and it is crap , worse than C.
The POO tends to be messed,cumbersome to read and understand and you always terminate to write more code than the vintage paradigm programming.
When i saw the video and i do a list of fallacies.
Strings -10:16
I acknowledge that C is very bad handling strings and with C++ enhances something. But Is it necesary using OOP ?
No , COBOL uses UNSTRING for splittig strings and STRING for concating string.
Printf - 11:30
This certain that the system out screen on C is bad with the type the casting . But the solution on C++ is putting sprats between variables instead the commas.
They have resolved us the headache but now we have eyepain.
Arrays 14:31
Here the POO begin to pervert the names , renaming with exotics names as "Collections" , let's go "the monkey is monkey although you wear him of silk"
The main problem with the arrays on C++ is that the programmer doesn't have to think , he goes to class get the method, and copies pastes a several times. The programmers loose the agilty of design algorithm.
On change C , too it exists funtions for handling arrays , but it has more flexibility on vary the code for adapting to situation than with C++, besides the programmer gains agility.
Namespaces 19:30
Other example of like the POO complicates the life , with stupids renames. The namespace is as the classic assigned of the libraries on C. But the great difficult that the old programmers see this , it is knowing that do this namespace ,because when they go to help , they find a giant holybook inside this there are other holybooks as russian dolls
Lambdas & polymorphs & cons & new 25:50-38:24
The pointers on C is a headache with the operators * and & due to a bad design on compared with the ASM opcodes.
Now , when she says that the polymorphism and the pointers are the same, that is for laughing.
Then the classical POO theory is dropped because if it does the same but without than the programmer handling pointers . Apart that the programmers loose the know-how of handling the indirect access, which is the diference with the visual basic.
On resume, i believe that don't have to leave to teach C due to this language has the main basic of the programming as manual control arrays and the pointers .
On change the C++ i believe is a bad example of the modern programming : ideological ,incoherent with the actual culture ecologist ( consumed every time more memory while it reduces the consume power),disordering and unstructured programming.
-
I acknowledge that C is very bad handling strings and with C++ enhances something. But Is it necesary using POO ?
No , COBOL use UNSTRING for splittig strings and STRING for concating string.
She underlined that string is a type, and each type comes with "operators"
e.g. if (string == string), the "==" is a type_string_operator
But the solution on C++ is putting sprats between variables instead the commas.
They have resolved us the headache but now we have eye pain
and "<<" is a type-operator, left-associative
-
POO
object oriented programming
O O P, on the mirror, is P O O
like UNIX and XINU, nice trick
-
I hope this isn't considered too off topic. I watched the following video recently, and found it very interesting. Beware! He speaks very quickly throughout the video; it took some getting used to.
https://www.youtube.com/watch?v=PDSvjwJ2M80 (https://www.youtube.com/watch?v=PDSvjwJ2M80)
I watched the video by Kate Gregory when it came out, and honestly, I hate that video. Maybe she's right, I don't know. I'm not in a qualified position to know. But it strikes me as incorrect and also the presentation was quite irritating, which is difficult to ignore.
-
For all these people with very strong opinions and saying that it's a blasphemy to use these "overbloated" things like vectors and strings and OOP instead of static tables, malloc and pointers - "stop teaching C" means "stop teaching C in C++ language course", not in "introduction to programming" course.
This talk was mainly about the big problem (that I also encountered in real life working with new programmers) that typical student after finishing typical C++ course writes code that won't pass any code review and often doesn't use any features of language that decided to choose it in the first place!
As a nice food for though there is another video from CppCon, explaining game for Commodore 64 written in modern C++ (and x86 to 6502 machine code translation) using all these naughty words like templates or classes showing how much can be done without any overhead in resulting machine code.
https://www.youtube.com/watch?v=zBkNBP00wJE (https://www.youtube.com/watch?v=zBkNBP00wJE)
-
That CppCon video was excellent. That embedded code can be written with zero overhead has caused me to rethink writing only in C. Of course, every concept he used is well beyond my existing understanding of C++ so I'll have to go back and watch it a couple more times. And hit the books...
-
Both of these video made me rethink about using C++ in an embedded system, I really enjoyed these two video.
I still think that we should teach C first, not anymore because of C++ is bloated for embedded, but more because using C++ correctly require a certain degree of experience. And expecting people to learn the base of programming, while also learning object oriented while also learning how to use C++ feature correctly to produce correct embedded system code is maybe too much.
But if people already had some exposure to programming (and i am talking about true exposure, not exposure to some obscure language like visual basic)... and are taking a course focused on embedded programming (with a prerequisite programming course experience) then yes, do it, having a full semester to learn how to use C++ feature while also keeping controle of the compiler output is feasable.
I don't think that learning a language like C before is bad before learning C++, it only expose the student to basic programming mechanism that will be used in C++ anyway : pointer, if, else, while... After learning those, they just need to learn object oriented. What is the difference between learning C first then C++ VS learning C++ without teaching OO now (because before learning OO, we learn how to do basic statement first like if, else...), except that in the first case not to much syntax is involved while in the second case, C++ has lot of syntax that could confuse some student?
Introductory to programming (C, python... but no OOP yet) --> Embedded system programming (MCU, interrupt, RTOS, using C++ the right way for embedded...)
-
Like some mining companies explore possibility of digging for gold,
I was exploring possibility of digging for Kernel development in C++
and this (http://stackoverflow.com/questions/12385485/kernel-development-and-c) is interesting :D
-
Here is another video by Dan Saks re: trying to get C programmers interested in C++. He starts with a slide that show an increasing trend to use C versus a decreasing trend to use C++ and that C is used three times as often as C++.
Somewhere around 1:16:00, he gets to the meat of the issue (from my point of view): C++ is a hard language - FAR more difficult to understand than C. 100x, 1000x? In any event, it is a LOT more difficult.
He follows up by saying that a lot of embedded programmers are EEs, not CSs. Their total exposure to programming in college was the instructor handing out copies of K&R and expecting to see LEDs blink.
The entire video is about how to approach the task of getting C programmers interested in C++. Only a couple of code examples and those weren't all that helpful since he doesn't really discuss the C++ implementation.
https://www.youtube.com/watch?v=D7Sd8A6_fYU (https://www.youtube.com/watch?v=D7Sd8A6_fYU)
I don't know why it is so difficult! Just develop an embedded project in C++ (including interrupts and, potentially, an RTOS) and serve it up as an example. Keyboard input via PS/2, LCD text screen output, some SPI or I2C, perhaps something truly difficult like a USB or Ethernet stack. I watched one of the other CppCon videos re: embedded development and I'm totally fascinated. Unfortunately, EVERY book I buy wants to develop an application to solve world hunger. That's not in my area of interest!
-
Kate's talk seems to be aimed at the instructors of "5 day C++" classes. Presumably (?) people who have programmed in bash or javascript, and are looking for info on a more efficient programming language. This is a pretty scary demographic; it reminds me of my teen son who wanted to wait till age 18 to get his driver's license so he wouldn't have to deal with "silly classes." :-)
You can't become a competent programmer in ANY language in 5 months, much less 5 days. So it becomes a matter of "what do you teach them first, so that they can do the most without hurting themselves." In that context, her suggestions make some sense...
-
For all these people with very strong opinions and saying that it's a blasphemy to use these "overbloated" things like vectors and strings and OOP instead of static tables, malloc and pointers - "stop teaching C" means "stop teaching C in C++ language course", not in "introduction to programming" course.
This talk was mainly about the big problem (that I also encountered in real life working with new programmers) that typical student after finishing typical C++ course writes code that won't pass any code review and often doesn't use any features of language that decided to choose it in the first place!
As a nice food for though there is another video from CppCon, explaining game for Commodore 64 written in modern C++ (and x86 to 6502 machine code translation) using all these naughty words like templates or classes showing how much can be done without any overhead in resulting machine code.
https://www.youtube.com/watch?v=zBkNBP00wJE (https://www.youtube.com/watch?v=zBkNBP00wJE)
finally watched that video
* very long whistle *
-
finally watched that video
* very long whistle *
And I am having a heck of a time finding reference material (books, class notes (no, not that kind of class)) that will get me started. I was blown away by the elegance of the code and the display of generated code was compelling. So, how to get started? I'm talking only about embedded programming.
I'm a 'cut and paste' kind of person. I like to find working examples and then incorporate them into my projects. So far, I'm not finding anything useful.
-
I'm a 'cut and paste' kind of person. I like to find working examples and then incorporate them into my projects.
Thief! ;)
But seriously, you should just use working examples as a guide to writing your own code. It will be more satisfying, you will learn more, and when you need to do something different you won't be out of your depth.
-
I saw a mention of ZeroMQ in the stackoverflow thread, the developer has some choice things (http://250bpm.com/blog:4) to say about C++ for lower level programming.
What seems to be necessary for C++ to be suitable for projects to be maintainable is a big stick, as always with programmers. The adherence to the C++ subset chosen for a project should be guaranteed by a code sanitizer, rather than depending on programmer discipline.
We need C++-.
-
I saw a mention of ZeroMQ in the stackoverflow thread, the developer has some choice things (http://250bpm.com/blog:4) to say about C++ for lower level programming.
What seems to be necessary for C++ to be suitable for projects to be maintainable is a big stick, as always with programmers. The adherence to the C++ subset chosen for a project should be guaranteed by a code sanitizer, rather than depending on programmer discipline.
We need C++-.
See the FQA (q.v.) :) Don't build castles on sand :)