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

0 Members and 1 Guest are viewing this topic.

Online hamster_nz

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

It sounds like a unrealistic fantasy - Let me riddle you this.... In this new language, what is returned by the equivalent of the sqrt(x) function, esp when x = 2.0?
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline helius

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

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2177
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #152 on: November 02, 2016, 05:59:54 pm »
Strange how many have an adversarial relationship with their computers and tools. Isn't the idea to work with the machine, not against it, to achieve your aim?

If is just that C (and I guess C++) is more up-front and honest (some say blunt and rude) and shows a machine's personality more strongly than other wishy/washy languages. Internally a computer can only do a limited set of things on a limited set of primitive data types, and hold that in memory, and on different platforms things can be different. It allows you to work with the hardware, not in spite of the hardware.

C was the first language to be honest with the programmer about that, and allowed programmers to write efficient code without knowing all the details (making it portable if written with care). That is why the language has been so well adopted and long lasting.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online hamster_nz

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

That is just waving the problem off... say a user is expecting to see the answer... "print sqrt(18)" what does your language give? "4"?, "3*sqrt(2.0)", an endless stream of digits? or "Sorry Dave, that answer can not be computed with the time left in the universe"

Or even worse
  i = sqrt(2.0)
  print "The square root of 2.0 is " i
  j = i * i
  print "Hang on, i * i is " j " which either isn't 2.0, or I didn't use the number printed above when calculating it!"

 
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online rstofer

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

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

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

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

Quote

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


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

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

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

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

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

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

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10501
  • Country: gb
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #155 on: November 02, 2016, 06:53:04 pm »
Strange how many have an adversarial relationship with their computers and tools. Isn't the idea to work with the machine, not against it, to achieve your aim?

If is just that C (and I guess C++) is more up-front and honest (some say blunt and rude) and shows a machine's personality more strongly than other wishy/washy languages. Internally a computer can only do a limited set of things on a limited set of primitive data types, and hold that in memory, and on different platforms things can be different. It allows you to work with the hardware, not in spite of the hardware.

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

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

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

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

The reasons for its longevity and adoption are more to do with history than technical merit. "Science advances one death at a time"; the same can be said for programming.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacy

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

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

Offline helius

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

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

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

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

Offline C

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

error, functionresult = sqrt(x)

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

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

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

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

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

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

Offline tggzzz

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

I don't have a valid opinion.

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

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

Offline John Coloccia

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

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


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

Online rstofer

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

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


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

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

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

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

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


 

Online hamster_nz

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

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

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

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

Offline Sal Ammoniac

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

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

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

Offline timb

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

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

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

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

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

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

Offline C

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

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


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

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

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

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

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

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

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



 

Offline andyturk

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

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

Offline helius

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

Offline andyturk

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

Offline setq

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

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

Offline tggzzz

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

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

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

Offline John Coloccia

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

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

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

Offline legacy

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

yep, the get started appears here, and

Quote
Linux

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

concerning linux, only ubuntu is in the list

edit:

and (stupid me) ...

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

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

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

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9327
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #173 on: November 03, 2016, 10:01:29 am »
my x86 laptop is 32bit my laptop is x86
fixed that for you...
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline timb

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

yep, the get started appears here, and

Quote
Linux

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

concerning linux, only ubuntu is in the list

edit:

and (stupid me) ...

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

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

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

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

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

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

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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf