Slashdot Mirror
C Programming Language 'Has Completed a Comeback' (infoworld.com)
InfoWorld reports that "the once-declining C language" has "completed a comeback" -- citing its rise to second place in the Tiobe Index of language popularity, the biggest rise of any language in 2017. An anonymous reader quotes their report:
Although the language only grew 1.69 percentage points in its rating year over year in the January index, that was enough beat out runners-up Python (1.21 percent gain) and Erlang (0.98 percent gain). Just five months ago, C was at its lowest-ever rating, at 6.477 percent; this month, its rating is 11.07 percent, once again putting it in second place behind Java (14.215 percent) -- although Java dropped 3.05 percent compared to January 2017. C's revival is possibly being fueled by its popularity in manufacturing and industry, including the automotive market, Tiobe believes...
But promising languages such as Julia, Hack, Rust, and Kotlin were not able to reach the top 20 or even the top 30, Tiobe pointed out. "Becoming part of the top 10 or even the top 20 requires a large ecosystem of communities and evangelists including conferences," said Paul Jansen, Tiobe managing director and compiler of the index. "This is not something that can be developed in one year's time."
For 2017 Tiobe also reports that after Java and C, the most popular programming languages were C++, Python, C#, JavaScript, Visual Basic .Net, R, PHP, and Perl.
The rival Pypl Popularity of Programming Language index calculates that the most popular languages are Java, Python, PHP, JavaScript, C#, C++, C, R, Objective-C, and Swift.
But promising languages such as Julia, Hack, Rust, and Kotlin were not able to reach the top 20 or even the top 30, Tiobe pointed out. "Becoming part of the top 10 or even the top 20 requires a large ecosystem of communities and evangelists including conferences," said Paul Jansen, Tiobe managing director and compiler of the index. "This is not something that can be developed in one year's time."
For 2017 Tiobe also reports that after Java and C, the most popular programming languages were C++, Python, C#, JavaScript, Visual Basic .Net, R, PHP, and Perl.
The rival Pypl Popularity of Programming Language index calculates that the most popular languages are Java, Python, PHP, JavaScript, C#, C++, C, R, Objective-C, and Swift.
C never went anywhere. Its mindshare was just continually eclipsed by whatever bullshit venture-captial-seeking-paradigm-of-the-month was en vogue for that month.
What changed? Did someone let slip that bitcoin mining can be done in C faster than with remote calls to jquery?
These aren't measures of how much languages are used, they're useless bullshit as asking which languages generate the most Twitter Tweets? Facebook posts? News articles?
Number of jobs held would be interesting.
So would number of unique jobs openings for each language.
With all the low cost ARM computers, perhap people appreciate the speed of C. Generally you get smaller faster programs. Or perhaps more people are working on the Linux kernel?
Nah, I'm guessing browser tech such as javascript and flash, mobile apps with embedded malware, and on the server side PHP the cause for entry.
And now we're seeing our hardware itself is deeply flawed...from mobile chips to desktop to server to mainframe.
At some point, don't know where that is myself, one needs to look at programming practices as well, and not just the languages being used.
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
No one is seriously going to try to use C for front end web development, just as no one is seriously going to try to use Javascript in an embedded microprocessor. So what this study is doing is just pointing out where the current jobs are.
Trying to compare languages, is like asking "which is better? a band saw or a screw driver?". They're entirely different. And anyone who doesn't understand that, simply doesn't have enough experience with other programming tools yet.
Oh Lord, seriously? This again? C is more dangerous than Java the way that a KA-Bar is more dangerous than a butter knife. If you take a real programming language, hamstring it, put a bib on it, and pull its teeth so it can process nothing more than strained baby food, sure, it won't be dangerous but then again it won't do much useful either.
Write a device driver in Java or Python. Or a kernel. C will always have a place in net-connected computers. You just don't hand a loaded gun to a child and expect he'll produce something useful without blowing his foot off. C is for grown-ups and when you get big and strong and if you eat all your spinach maybe when you grow up you'll do system programming too. Until then, feel free to play around with interpreted languages that pen you in a coral so you don't do anything stupid and feel free to pretend that JIT really does mean it's compiled and just as fast as native code.
Programming practices. Yeah ok.
But people are people, programmers are programmers, and there are bell curves of skill, care and attention, schedule reasonableness under which programs are created.
So let's not assume every programmer writing a potentially security-relevant piece of code is a really good, well educated in best practices, really safe designer and coder with enough time for testing and iteration. Assuming that would be naive.
So why not protect against common errors using the programming language constraints and checks? Most of these protections can be done with very little cost, performance wise or in loss of program expressive power.
We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.
Where are we going and why are we in a handbasket?
I consider this the transition to a more stable period. For some time it was unclear how functions would be split between programming languages. All kind of ideas were in the room, with interesting new contenders. Still the programming community decided that the areas covered by Java, Javascript, C, Python are well distributed in the way in which they are and that "good enough is still good".
C# (competitor to C++ and Java in my eyes) seems to be dying. Swift doenst take over from objective C as fast as that one is going down. So for low-level languages nothing else is left. OOP and Data Architectures are firmly in the hand of Java, which has a very small overlap and a very good synergy with C. Python coesists in other areas, and hurts neither of he two languages.
So in some sense: the war is over and java, (C+C++), python, Javascript have won for now.
I disagree. Too much of the modern economy now depends upon code to leave safety to the whims, skills or vanity of the programmer. Frankly, the "trust me, I'm good" argument isn't good enough and neither are you. Type safety, bounds checking, protected memory and access control are no longer optional in 2018. You either begin accepting these things or the product liability lawyers are going to win out in court eventually and you will be held financially liable for every bug in your C code. Software has long enjoyed a special immunity to liability lawsuits, but that protection is eroding and rightly so. The days of "trust me, I'm the Jedi Master of C code" are numbered. Better to participate in the transition to safer programming languages and practices than be bankrupted by lawyers, lawsuits and politicians looking for a villain to blame.
> people are people
Maybe if you aimed higher than that, you would be a better C programmer.
Just saying.
If your C standard library doesn't have ffs(), then... sorry, Windows user. I guess there's always _BitScanForward or __lzcnt.
Oh, and if your CPU uses clz to count trailing zeroes, you should report that as a bug.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
You're not suggesting that we make programs less efficient than possible because we have more resources, are you? IMO, while going nuts is not helpful, we shouldn't use resources inefficiently, or the like, "just because" we have the room - not only that, but not every programming project, career, involves software that has that sort of safety - embedded systems, for instance.
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
Everything on planet freaking earth has firmware in it now and guess what compiler makes the smallest binaries that can talk to hardware?
Yes, that's right C.
Python can talk to C, but you aren't going to write firmware or low level interrupt handling code (like reading IR pulses) or monitoring an I2C bus.
Java is C's fat lazy son that lives in the basement and consumes all available resources can do things eventually, if you give him enough resources, time, and be able to tolerate the odor.
As long as computer architecture remains constant, C will be king. It's fast, small, and get's sh*t done now. Plus once you write it in C, you can call it from any other modern programming language like Python, Java, Objective-C, Swift, etc ...
I went to a graduation party of a graduating Aerospace engineer last weekend and his advice was learn C, learn simulation and solving software like Mathematica, learn how to work in teams, and be multidiscipline in career focus for great success. He graduated from Perdue.
No bounds checking, no type checking. In 2018. Get serious.
A halfway good programmer doesn't need to trust the language to do that for him and is capable of ensuring boundaries. The problem is that halfway good programmers have become scarce, and today's coders are content to leave critical parts to a compiler they don't understand and black box libraries they don't know what do behind the scenes. So they need the handholding.
Attitudes like this are why people need a computer 600,000 times faster with 262144 times the memory in order to load something just to check their e-mail. I don't use Rust. I use Go when I must. It's not a bad language as new languages go - Syncthing, a project I've contributed to, uses Go and it's not terrible.
In a way you're correct. I'd agree that only about 10% of software really needs the performance and versatility of C. Most others can get away with C++, for better organization, or some other natively compiled code. Go if you like. Or Pascal if you want something old school but still strongly type checked. I actually use Pascal quite a bit myself, simply because of the free Lazarus environment. Even interpreted stuff has its place, but far less than it is used for. Just as only about 10% of software needs the power and versatility of C, only about 10% of software is appropriate for an interpreted environment. The problem is, kids coming out of school high on what some unfortunate profs (who often don't have to work in the real world) have been feeding them then start all these projects in Python and Java that have no place being written in an interpreted language. Python is good for small front ends. But then someone will want to get fancy and use PyGTK or some other frankenlibrary or else what started as a little front end simply grows beyond what is really appropriate and it becomes non-portable and a nightmare fast.
I actually have nothing against any language. I have serious problems when they are used inappropriately, though, and I have even more serious problems when what has been the best swiss army knife programmers have ever had for the better part of half a century is slagged in favour of some du jour. C never lost its place, and won't for the foreseeable future. For system programming it's not just unparalleled, it's often just simply indispensable. Computers are not people, they are electrical devices with bits and bytes, and sometimes you just need a language that embraces that rather than tries to hide it like its some dirty secret.
I'm not saying C did or did not come back, or did or did not go away. I am saying, you won't know from Tiobe, it way too random. They count language questions, not language usage, and don't make the slightest attempt to correct for predictable skew like selection bias due to who hangs out there as opposed to, say, stackoverflow.
My totally on reliable take on it? C dev population stays about the same: very few, very skilled, and very highly paid. Because of the latter, the number of C wannabes spikes from time to time, but don't worry, they will go away after they ask a few questions and still can't code.
When all you have is a hammer, every problem starts to look like a thumb.
Someone who thinks that C is the only performant programming language today? Someone who's never heard of Go or rust...
C and c++ (same code generator) kick the tails of go and rust, the former more so.
When all you have is a hammer, every problem starts to look like a thumb.
You are right in general...but wrong here.
This report is not a beauty context or any other comparison of tools but rather statistics of web searches. As such it got reported and misinterpreted as "popularity" as if it was a preference.
4wdloop
Or maybe it's a reflection that nearly every developer out there knows C to some degree and doesn't have to search for help as much?
Maybe it means there are more older C devs that are more likely to go to a book than Stack overflow?
Either way, it's a garbage metric designed to generate lazy clickbait articles, like this one.
I'm a good cook. I'm a fantastic eater. - Steven Brust
But people are people, programmers are programmers, and there are bell curves of skill, care and attention, schedule reasonableness under which programs are created.
So let's not assume every programmer writing a potentially security-relevant piece of code is a really good, well educated in best practices, really safe designer and coder with enough time for testing and iteration. Assuming that would be naive.
It would be naive to assume general purpose language selection makes a meaningful difference with regards to security outcomes.
It's up to the architect to manage risk by selecting appropriate tools and methodologies to best address specific problem domain. Placing programmers in an environment that ensures failure by giving them the wrong tool for the job before them or where they are required to always be extra careful in order to avert disaster is extremely counterproductive.
So why not protect against common errors using the programming language constraints and checks? Most of these protections can be done with very little cost, performance wise or in loss of program expressive power.
It is not clear to me specifically what you believe is not being done that can be.
Compile time checks, static analysis, profilers, fuzzers and runtime bounds check code inserted automatically by compilers by default are generally available to programmers at little to no cost. Quite a lot of the old standard C library has over the years been marked as hazardous to your health by modern compilers.
We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.
Obvious solutions to obvious problems already exist. Yet it does not follow obvious problems necessarily have tractable solutions. For example designing a car incapable of ever running anyone over is reasonably beyond current technology even though instances of reasonable measures to mitigate the problem exist.
One thing that has always fascinated me over the years is the lack of sufficient advances in outcomes commensurate with development and selection of new languages. Most instances of productivity gains and capabilities can be traced back to hard won incremental development of complex domain specific systems and hardware improvements rather than advancement of underlying general purpose language.
The fact virtually all system programming is still some flavor of C in my view speaks for the difference between hype, wishful thinking and reality. We've had decades and so far very little of substance to show for it.
Decade ago when processors that could execute java byte code natively were taped out I actually believed this would change. I assumed we would all be running java everything by now and this is from someone who personally never cared for the language.
I seriously used C for web development (an old intranet system that was written when CGI was a new thing) It wasn't as hard as it may sound, nor did it take much more time to do than if I were to use a javascript framework of the week. it actually it took less effort than when having to deal with js / npm / webpack etc. These days I would use python on the back end if starting a new web project, with just enough front end scripting libs (jquery, bootstrap) to get on with the job, but I'd still prefer to code in C instead of the clusterfuck that is modern javascript
if your CPU uses clz to count trailing zeroes, you should report that as a bug.
Not necessarily. Use s = (s & (s - 1)) ^ s to clear all 1 bits other than the least significant, giving a "one-hot" integer. Then you can count leading zeroes and use that to infer trailing zeroes. It might look like the following (in a generic pseudo-assembly language):
Safety checks and transparent abstractions cost cycles and memory accesses.
//The programmer has to state this explicitly or it's a silent runtime error.
try{
for(i=0; i<10; i++){ if(i<0 || > a->length){
throw(zOMGEXception);
}
a->data[i] = i; }
catch(){
//The language feature doesn't relieve you of any responsibility
}
will always be marginally slower than
for(i=0; i<10; i++){
data[i] = i;
}
Really you can accomplish everything in C, Java and BASH.
Build and deploy thousands of machines, and you don't have to throw 30 plus years of systems engineering under the bus because some idiot out of college wants to use python.
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Lazarus gets you the Object Pascal derived syntax from Turbo Pascal and Delphi, and provides an IDE available on multiple platforms. I've had zero problems installing it on several systems, mostly for quick and dirty projects where I didn't necessarily want to use C.
“Common sense is not so common.” — Voltaire
Maybe we just need better automated testing?
C is easy if you don't try to do anything clever. Let the compiler be clever.
But often there is no testing at all. Maybe in the future everything you compile gets fuzzed.
There is absolutely no reason at all to think it is better to package this into the language, when it can be placed anywhere in the build process.
FTFY
Sent from my ASR33 using ASCII
Because it is not American.
Sent from my ASR33 using ASCII
Using more memory or more disk space is not inefficient.
A la contrair: it is nearly always more speed efficient than using less.
The historic reason why people tried to use less memory and less disk space is simple: there was not more available. Bottom line it does not matter at all if you squeeze your smartness to put a data structure and the relevant algorithms into the smallest amount as possible (of memory and disk space) or if you rather use your smartness to develop a maintainable, extendable, scaling, multi threaded/multi session distributed algorithm. If you are smart enough you can do both, but most people for some odd reason believe that programmers focusing on the former are smarter than the ones focusing on the later.
I disagree.
Hint: load a small C program on various *nix systems. Then check how much swap space the tiny program occupies, then ponder why that varies from *nix system to system and then ponder more, why some *nix systems allocate a huge "process space" in the swap space while the program only needs a few megabytes (a few as in significantly below 10MB)
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Actually there are plenty of highly interesting and good paying projects for which C is the only real option. A decade ago I was a C and C++ programmer, and pretty good if I say so myself. I cared to write bullet proof and well documented C code, and companies paid me a lot of money to do just that. I wrote firmware for the 2000 series Texas Instruments DSP to control the semiconductor for a telecom laser. That was all C without even standard libraries because the DSP only had a couple K of RAM and ROM.
I wrote software for a set of kernel level linux deamons that did IO via optical interfaces with GPS sattelites or a spy camera that was going inn space. My inter process communication was basically all 'C with classes' and the communication with the interface was all straight C because when delaing with PCI boards and ISA interfaces, you're dealing with mapped memory that you have to write to at specific addresses following certain protocols
All those projects were in C, and among the most interesting and rewarding projects I've done.
A halfway good programmer doesn't need to trust the language to do that for him and is capable of ensuring boundaries. The problem is that halfway good programmers have become scarce,
Halfway good programmers have ALWAYS been scarse.
Even if I was a great programmer in general, I sure wasn't last week when I was sleep deprived and my head felt stuffed with wool because of having a cold.
SJW n. One who posts facts.
Actually I think SQL injection probably accounts for a larger share than overflows
I don't have a more recent statistic, but an MSR study from 2012 found that around 70% of all exploited security vulnerabilities are buffer overflows.
I am TheRaven on Soylent News
Well,
joking aside there is a quite complete and portable Pascal: https://www.freepascal.org/
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
How come go is slower than java? It compiles to native code and is more low level
Compiling to native code isn't always an advantage. For a trivial example, consider a Java and a Go code fragment that calls the same method on objects of the same type in a loop. In the Go version, because of the AOT compilation model, this will always be a function call unless the compiler can statically prove that the object type is always the same for every possible invocation of the program. The Java version will collect profiling information as it runs, determine that the same method is called every time, and inline it with a cheap check. The JIT'd Java version will be faster.
This even happens within the same language. On Android, Java is first JIT'd and then AOT compiled over night. Most of the time, the AOT version is faster because the compiler can spent several minutes of time (and not worry about power consumption because it only does this when the device is plugged in). In some cases, it's slower because the JIT can optimise for what happens most of the time, wheres the AOT compiler most optimise for what can possibly happen.
I'd also dispute the idea that Go is more low-level than Java. Both are garbage collected, both have dynamic dispatch, both have roughly the same set of primitive types and of intraprocedural flow control constructs.
I am TheRaven on Soylent News
Add to that, a memory model where data races have undefined behaviour combined with a type system that makes it impossible to check for that aliased-xor-mutable property. Complex Go programs are going to end up with far more subtle and difficult to debug problems than C ones.
I am TheRaven on Soylent News
A very small subset of programmers, working with formal verification tools. It's not that we don't know how to write correct code, it's that we don't know how to write correct code cheaply. The seL4 team estimates their development cost at around 30 times that of a state-of-the-art conventional software engineering team with full test coverage that isn't using formal methods. That's not a cost that people are willing to pay for all software, but it is a cost that's easily amortised when it's just for a relatively small set of things in the trusted computing base.
I am TheRaven on Soylent News
Why intentionally sacrifice performance? Todays processors may be many thousands of times faster than the early ones, but it doesn't make sense to then slow them down with overweight inefficient code.
Performance and efficiency is still very important, slow code costs money in extra execution time, increased power consumption, increased hardware requirements, especially at large scale. Code which is 10% slower running on a single user's desktop might not make much of a difference, but run that code across thousands of systems or run thousands of instances of it and you've got huge wastage.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The basic job of a programmer is to automate things: to make a computer do things, rather than a human. That is the entire point of all programming. What kind of programmer, when faced with a problem for which there is an existing generic solution with adequate performance prefers to write an ad-hoc solution? A poor one. Yet that's exactly what you're advocating: your notion of a 'halfway good programmer' is one that doesn't make use of the results of programming.
There are places where manual memory management, deterministic performance, and pointer arithmetic are absolutely essential requirements. In these situations, C or C++ are about the only options (Rust might be, but most of these projects require long-term maintenance and Rust is far too young to consider for that kind of project). For everything else, your choice is either reinvent the wheel in an ad-hoc way, or use one that's been well tested and optimised.
I am TheRaven on Soylent News
just as no one is seriously going to try to use Javascript in an embedded microprocessor
I draw your attention to JerryScript, developed by Samsung as a lightweight JavaScript interpreter specifically designed for running in embedded microprocessors.
I am TheRaven on Soylent News
On the other hand, my understanding is that Go's methods are (intentionally) sufficiently dumb that they can be called with an indirect jump that can be reasonably predicted by current breed of CPUs
That depends on whether you use an interface or not. If you don't, then it's equivalent to calling a final Java method (you can tell statically what the destination will be). If you do, then (as with Java) it's an indirect jump via a vtable. The problem with method calling is not so much the cost of the jump, it's the cost of call frame setup and of missed optimisation opportunities. For a small method, you may end up doing 2-3 instructions of real work, but 10-15 instructions of setup. Even if the jump is free, you're still paying a big penalty for invoking it at all. You're also missing out on later optimisation opportunities and the ability to do things like interleaving two dependent memory accesses from the method with in-regsiter operations from later or earlier on to help keep pipelines full. These days, the main reason that compilers do inlining is to expose more optimisation opportunities. The same is true of loop unrolling, where modern branch predictors have mostly eliminated the costs of repeated loop iterations (though rename register pressure can still be a problem).
I am TheRaven on Soylent News
We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.
We can also design cars to be incapable of driving faster than 30 miles per hour, because that is determined (by a committee of "experts", of course) to be the maximum "safe" speed that embraces 99% of all drivers on the road.
We'd all just pay for this safety. Pay in time. Pay in convenience. Pay in no longer having any possibility of "racing" a car or pushing the performance envelope for cars. Pay in no longer permitting anybody, anywhere, to design a car that does NOT have the speed governor built right in, and use all of the other crap that the CoE decided was necessary for even a raging drunk to be safe behind the wheel, including the car-surround baby bumpers and reinforced passenger compartment and feature that won't let the car start without all passengers wearing a kevlar vest and safety helmet.
This is an argument that is as old as time. If you like working with a fascist language that only permits you do allocate memory through an opaque interface that cheerfully trades off speed for an illusion of security, there are many to choose from. C, it is absolutely true, has comparatively few safety nets, although there are tools and techniques for making it as safe as you like. It is also true that it is difficult to write more efficient code than one can write in C short of coding in assembler, and C allows one to inline assembler for those cases where only assembler will let you access certain systems features (instead of waiting until the CoE decide that they are "safe"). Similarly, even good old Fortran has its place if you are doing massive linear algebra and want to optimize it for bleeding edge CPU features.
Could one modify C a lot more minimally, to make it safer than it is by nature while still not enforcing the OO kool-ade and outright prohibiting the use of malloc and pointers? Sure, probably -- some of the tools out there basically do that. But there are times when one can write code with malloc and pointers that is just plain magic compared to what one can get with OO opaque memory management.
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.
PyCAM and PiTiVi are two off the top of my head. PyCAM is CPU bound and Python doesn't do its calculations any favours. It's sluggish at the best of times and almost impossible to produce versions that work cross platform. PiTiVi isn't terrible as basically it's just a front end for GStreamer, and as that it's a good use of Python. But it's not cross platform, which defeats half the purpose.
Interestingly, looking at the PiTiVi web site, on the contributing page:
Which just about sums up Python. Great for quick and dirty little tools, good for a front end, but bad in that most serious front ends require a widget kit that will be problematic for cross-platform, and if you want to do serious work, go to C.
Not sure what native compiler you're thinking of. Maybe I do live under a rock. GCJ is gone - GNU is trying to sweep it under the carpet as the bad idea it was, since it never really worked well (read at all). Ok, doing some research I see that there is some product called Escelsior Jet that claims to be a compiler. However, from its web site:
So it's not clear if any general purpose Java app can be rendered into 100% native code. It looks like it will do all the pure Java, but how many normally used Java classes this includes is another question. I have never ever heard of Excelsior Jet before, and neither has Wikipedia. It's mentioned in a couple Stack Exchange questions, likely posts from employees at Excelsior Jet in my assessment.
If it is JIT you are speaking of, JIT is not native. JIT is a marketing term for various usually caching optimizations intended to make interpreting bytecode less slow. JIT means different things to different interpreters, but it always involves run-time conversion of bytecode to machine code, which is what interpreting is, and despite what marketing people say, is universally slower than AOT conversion to purely native code.
This is just wrong. Windows kernel, plus many device drivers. BSD kernel plus most device drivers (except in MacOS which uses a subset of C++ for device drivers). Linux kernel, as you mention, plus almost all device drivers. Every other Unix kernel and all their device drivers. Virtually the whole OS for most real time OSes. That right there is 99.99% of computing devices on the planet. C is very large on the military scene right now. Most Western navy's combat management systems are more or less entirely C, or use such a stripped down subset of C++ that you might as well call it C anyway (see below). Some colleagues of mine on the aircraft side of things played around with realtime java a bit for avionics, but it didn't really go anywhere.
Some will use C++ for drivers, though in many operating systems that's problematic because of the runtime, so they use it stripped down again. Mayb