Most Popular Programming Languages, Surveyed by Jetbrains - Page 1
Forum section: electronics / general

author: windsmurf
author_rank: Frequent Contributor
timestamp: June 20, 2019, 03:00:09 am
content: Its notable that Rust is the only programming language with a "planning to use" vs "using" ratio greater than one.https://www.jetbrains.com/lp/devecosystem-2019/

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 20, 2019, 10:25:26 am
content: HTML and CSS are markup languages, and have nothing to do with programming. It is like asking whether decimal digits should be considered upper or lower case.Not being able to distinguish between programming and markup languages is a pretty good indicator the authors have zero understanding of the matter they purport to have conducted a survey on; it is garbage, not worth drawing any sort of conclusions whatsoever.In particular, self-reporting surveys are heavily weighted by buzzword technology reports, because the set of people who are the most likely to flit between tools without never learning enough of anything to actually use the tool for anything productive, is exactly the set of people most likely to self-report to surveys. Thus, such surveys are more reliable as indicators on how well various buzzword marketing strategies are performing, than anything to do with the actual use of said technologies.

author: Karel
author_rank: Super Contributor
timestamp: June 20, 2019, 11:38:00 am
content: https://www.tiobe.com/tiobe-index/

author: Ampera
author_rank: Super Contributor
timestamp: June 20, 2019, 09:18:22 pm
content: I don't really even know where Java gets used. I believe Android has its own Java stuff going on, and it was very popular for thinclients, PoS, and server backend systems, so maybe I've answered my own question.I personally use Java and C/C++, and enjoy them both for their benefits, but if I had to only ever use one, it would be C/C++.

author: Karel
author_rank: Super Contributor
timestamp: June 21, 2019, 06:36:11 am
content: Quote from: Ampera on June 20, 2019, 09:18:22 pmIt's the most used serverside/backend programming language.On the desktop it's practically dead.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: June 21, 2019, 08:18:44 am
content: Quote from: windsmurf on June 20, 2019, 03:00:09 amGiven the low numbers and high margin of error, it's probably just random noise. So not really notable at all.

author: tszaboo
author_rank: Super Contributor
timestamp: June 21, 2019, 08:36:15 am
content: These tests are the definition of "selection bias".It's like when stack overflow publishes that 85% of programmers use javascript.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 21, 2019, 05:32:31 pm
content: Quote from: NANDBlog on June 21, 2019, 08:36:15 amMay be they do. I had to do something with my Website and I have used Javascript. There's no choice actually. If someone asked me if I had used Javascript last year, I'd say yes. But I am not really Javascript programmer, am I?

author: rrinker
author_rank: Super Contributor
timestamp: June 21, 2019, 07:08:42 pm
content: Exactly. "Use" it? Why, yes, I have. Use it as my first choice? Hardly.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 23, 2019, 03:27:15 pm
content: Quote from: Ampera on June 20, 2019, 09:18:22 pmThere still is a massive legacy Java support infrastructure. A lot of total and utter crap was produced in Java between about 2000-2010, it's used in mission critical public systems more than you would guess. Now these buggy, bloated, 100 million lines of code systems are still in production, the original authors have burned out, and they require maintenance.It's not a new argument for Java: learn it, and you'll have a job. Java won't go out of "fashion" in the job market, even when most of the sane technological people would like to just forget it never existed.It had some nice ideas though.Studies like this result inhugevariations between studies, indicating that very few of these succeed in finding even a remotely random sampling. A large metastudy could provide some insight, but OTOH, what purpose do these surveys serve? It's like asking which is most popular:1) hammer2) nail3) screwdriver4) drill bit5) asphalt6) orange juice

author: Mattjd
author_rank: Regular Contributor
timestamp: June 26, 2019, 10:41:15 am
content: Rust seems like the new alternative to C++. Its supposedly safer by detecting and not even allowing unsafe coding practices. I don't know much C++ myself, I know far more Matlab, C, Python (in that order). I did however go to school with someone who is a bit of an Electrical-Computer hotshot and swears by Rust. I tend to trust this guys opinion as I've found him to be very intelligent, knew a lot before even coming in as both his parents are engineers.Now I'm not trying to convince you guys to use Rust because of what my peer thinks but just that I'm curious to what you all think of Rust.

author: Karel
author_rank: Super Contributor
timestamp: June 26, 2019, 12:39:24 pm
content: In the context of operating systems, ucontrollers and embedded, nothing is going to replace C language. Despite many attempts from many new languages...- C is supported best and everywhere- it's the most efficient language (apart from assembly)- it has a lot of legacyEvery now and then a new attempt is done to compete with or replace C.And every time they fail, whether you like it or not.Personally, what I like about C, is that it provides me possibilities, without imposing policies.In other words, I can do what I want, not just what some other person thinks is best/safe for me...If that's a good thing for you too or not, depends completely to you.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: June 28, 2019, 07:22:47 pm
content: Quote from: Mattjd on June 26, 2019, 10:41:15 amUnfortunately, after 30 years professional in software, I find the main problem is that "a bad programmer can write bad code in any language", to paraphrase the famous saying. And most programmers are pretty bad.Good programmers avoid unsafe practices anyway, so new and better languages don't provide the advantage that is hoped.

author: Jr460
author_rank: Regular Contributor
timestamp: June 28, 2019, 11:53:12 pm
content: Poor survey for many reason that other have already stated.At work I joke that we have issues at all levels of management because they think all applications have 3 parts, web fronted, web backend, and a database. They have been told that is how things work and thus can't imagine anything else. This leads to strange fights at times, like demanding everyone pass all applications through a reverse web proxy because it will be more secure. When they ask why app X is not using the proxy and you say, it can't, they think you must be lying, because it isn't database server, so it must have a web part.I do sysadmin work, but being around a while I know what are major apps are using. One is Java and the other is C, neither is a "web" application but they both have an admin interface into them that is web based. Funny thing was just today someone that takes care of some very small minor apps put in a trouble report that the COBOL compiler on UNIX is giving a error about reaching a license server.We once had an app that was written in Ada. Long before I got there, someone thought it was the new cool thing to use, this was before they started even teaching C in CS classes. Ended up that only one guy knew Ada, the app was mess. I saw the code once, and it didn't matter what you used, it was just mess in any language. The one guy that worked on this important app was a "strange" guy and also fought the re-write in C++. And then the re-write ran like crap so they pulled in someone I knew to look at it. Well someone said XML was the new wave they had to support, so the writers took to XML for everything..... did I say everything..... All internal variables were stored in XML. Think of the work done to increase a counter by one. On many CICS CPUs it compiles down to one instruction, but in this case it the runtime had to parse an XML string find the variable, convert from text to binary, do the inc, convert it back and then rebuild the chunk of XML with the new string in it.Moral, you can write bad stuff in any language.Most the code I wrote has been a shell script of some sort, then ASM was next, and if I really needed a higher level lang then I wrote my OS utilities in Fortran. Why, because I knew it well, I could write clear simple code for what I wanted to do, and it compiled to nice fast code.I point people to....https://web.mit.edu/humor/Computers/real.programmers

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: August 10, 2019, 03:08:28 am
content: I have bee programming for 40+ years.Started off in 1980 with machine code (not even assembler.)Typed in Z80 hex codes into a Microprofessor.Then moved onto BASIC.The in my job was asked to do some Z80 assembly language.1984 I got a job as a design consultant working mostly on PIC's ,but some PC DOS and other micros too.In about 2000 I got into Delphi Pascal for PCB design program.In 2008 I got into C#.I wasn't happy with speed of C# so moved onto C++.C++ was much faster at screen redraw than C#.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: August 10, 2019, 04:33:45 am
content: Quote from: Siwastaja on June 23, 2019, 03:27:15 pmThis is the key. Different languages are better suited to different jobs. And like hammers they get used for jobs they aren't well suited because that is what is available or is what the coder knows. C is widely popular because a: It does pretty well in a lot of areas and there is little you can't do if you work at it, b: It is available everywhere and c: A lot of people know it. My favorite example of this is scientific programming. You can do it in C, but it is not naturally suited for the task. But it is used widely in this area.Another mistake that is often made when doing these surveys is confusing languages with compilers. A good language and a bad compiler will result in a survey death, while marginal or bad languages with an excellent compiler can do well. This latter combination explains the success of Turbo Pascal in the early PC era. Pascal is a nice language but really not well suited to tasks beyond the educational purposes it was designed for. But the excellent IDE and compiler (for its time) done by Borlund kicked it into the mainstream for a while. It took a while for other languages to catch up and begin to be evaluated on the language characteristics.

author: ebclr
author_rank: Super Contributor
timestamp: August 10, 2019, 08:46:29 am
content: It's amazing that pascal ( Delphi ) does not appear on that survey, I guess Embarcadero is in trouble

author: Mechatrommer
author_rank: Super Contributor
timestamp: August 10, 2019, 11:36:53 am
content: Quote from: nigelwright7557 on August 10, 2019, 03:08:28 amcirca 2000 i got to choose between Fortran, Delphi, C/C++, VBasic. i keep VB and C/C++ until today. and further later came C#, i looked at the sample code, i was put off and never touch it again. i wonder how you (as a consultant) missed C/C++ which came much much earlier than C#. now my VB is phased out, if anything that is still has a way long to go, its C/C++, even if it has to bury under some fancier and managed named language.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 10, 2019, 04:15:33 pm
content: Quote from: Mechatrommer on August 10, 2019, 11:36:53 amThat's an "interesting" move indeed, but I wouldn't be that surprised either, coming from Delphi. I can perfectly understand someone proficient in Delphi would keep using it until it became unsupported. It was a pretty decent version of Pascal, with nice libraries.One thing that often eludes the discussion when talking about programming languages is everything that revolves around them - not just the core languages themselves.Especially for desktop app development, I think many developers/companies have chosen languages not just for their particular merits and features, but because enough tools and libraries would be readily available for rapid development. GUI development in particular was often a key decision factor.As I remember, Delphi came with nice libraries for GUI development. It became also easier to develop GUIs with C# than directly with C or C++. C++ already made GUI development much easier and faster than C, thanks to all the classes that became quickly available, and I do think it was actually one of the main incentives for switching to C++, even before the hype factor. The language itself was secondary IMO. What matters for most companies and most developers is the ability to complete a given development faster. I think it's the same that made Java extremely popular: not just the language itself, but everything around it that made app development much easier and faster...

author: rstofer
author_rank: Super Contributor
timestamp: August 10, 2019, 04:41:37 pm
content: Quote from: windsmurf on June 20, 2019, 03:00:09 amWhen nobody uses a language, even one reply of 'planning to use' drives the ratio > 1.That's like saying my one-man software shop if growing faster than Microsoft. Of course it could! I earned $1 last year and $5 this year, I'm growing at 500%Another thing about the survey: It is heavily oriented toward web development and certain languages, like C, aren't used for scripting. Yet every operating system on the planet is written in C. Even in the Android world where the apps are written in Java (guessing), the underlying operating system is Linux and the Linux kernel is written in C.But even a metric like "lines of code in use" would be skewed toward scripting languages since the world is focused on web development. As important as Javascript is, the interpreter is written in C++. OTOH, adding up all the C code in operating systems would result in a pretty big number.Don't take these biased surveys too seriously. C runs the world and Fortran tells it how fast to move and they have done so for more than 50 years. Everything else is just a passing fad.

author: rstofer
author_rank: Super Contributor
timestamp: August 10, 2019, 05:49:21 pm
content: Quote from: CatalinaWOW on August 10, 2019, 04:33:45 amAnd, seemingly without fanfare, Fortran is still used in the scientific community. For dealing with numbers, I prefer it but I would settle for C if I had to. Pascal is the most elegant language I have ever used and if I had to implement business logic, this is where I would start.There's a reason that every chip vendor has some version of C available just as soon as they ship the device. It's even easier when the core is based on ARM.

author: Karel
author_rank: Super Contributor
timestamp: August 11, 2019, 07:37:16 am
content: Quote from: rstofer on August 10, 2019, 04:41:37 pmThis.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 20, 2019, 09:34:13 pm
content: Quote from: rstofer on August 10, 2019, 05:49:21 pmI've never liked FORTRAN much, but yes it's still used significantly in the scientific community. I think GCC has decent support for it.If you're interested in Pascal, I recommend this:https://www.freepascal.org/Of course you may also consider derivatives such as Oberon and Modula(-3).

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: August 22, 2019, 11:58:22 pm
content: I use Assembly language on small PIC microcontrollers with small memory.On the 32 bit PIC micros I use C and Harmony.On the PC I use c++ for speed or C# WPF for ease of programming.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 23, 2019, 03:11:15 pm
content: Quote from: SiliconWizard on August 10, 2019, 04:15:33 pmTheir GUI library (VCL) was overblown, deficient, and buggy. But they had a crazy-fast Pascal compiler. It could compile big projects in less than a second, and it produced good quality code. I've never seen any other compiler which would come even close. They completely re-wrote the compiler ca. 2010, so there's nothing good left in Delphi

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 23, 2019, 05:37:32 pm
content: Quote from: NorthGuy on August 23, 2019, 03:11:15 pmMaybe, I don't know. Never used it, but it was somewhat popular at the time. Then again isn't that true for almost all general-purpose GUI libraries out there?All I know is that Delphi-based apps tended to be rather stable and nice-looking.Quote from: NorthGuy on August 23, 2019, 03:11:15 pmFor those remotely interested, there is the open Lazarus environment which doesn't seem too shabby (based on freepascal).

author: Mechatrommer
author_rank: Super Contributor
timestamp: August 23, 2019, 06:48:04 pm
content: Quote from: NorthGuy on August 23, 2019, 03:11:15 pmthe trick is to not recompile intermediate objects that their source files unchanged. similar to other enterprise grade C/C++ IDE such as Ms Visual Studio. seems like a lost trick when young people thought its ok to brute force recompile all on modern faster CPU, or are they the professionals who think its not worth their time? because they are pro, and pro need to complete things fast? at the stake of users worst experience, so long the money got into their pocket. the worst case i've seen is Arduino IDE but well, its free who can complaint? Borland Delphi aimed to rival its contender Ms Visual Basic. i had a chance to try Borland Delphi and C++ but i had problem building DLL with them to interconnect with Delphi apps, and never got it figured out. this was the main reason i keep Ms VB (for GUI) and VC++ (for near assembly speed grade DLL), the second main reason is the pascal criptic syntax, compared to the lovely VB.

author: Kleinstein
author_rank: Super Contributor
timestamp: August 23, 2019, 08:23:12 pm
content: The Turbo Pascal and likely the later Delphi compiler was really amazingly fast - or should we say modern C compilers and many other are amazingly slow. I remember an old Pascal version at the C64 that was nearly as fast - however that one cheated a little, they already saved the source coder with special codes for the main language elements.C is often slow, because all the imported .h files and #defines, that are recompiled every time. Turbo pascal, Modula and similar hat the files precompiled, as more elements for using multiple files are part of the language definition and not just simple include a text file to the source and do lots of defines. In C, a lot is done by the pre-processing step, and the actual compiler sees a much different final C code than the source code. Even quite some part of the library code goes through the compiler every time, as the actual languish elements are rather limited - much comes from the std. libraries.The common GCC also does quite some optimization - much of the takes time though only giving slightly fast code. They just spend the time they have from a modern PC. An old compiler on a new PC tends to run fast, as it was made for a PC that was ways slower. So slow optimizations could no be used.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 23, 2019, 09:34:19 pm
content: Quote from: Mechatrommer on August 23, 2019, 06:48:04 pmI actually re-compile everything every time, and it runs very fast. The biggest project I have is about 400k lines. Delphi compiles everything under a second. You just press a button and see your program running.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2019, 03:02:33 am
content: Quote from: Mechatrommer on August 23, 2019, 06:48:04 pmWhat?This is howmakehas worked for some forty-odd years, now, in the Unix world. (It compares the modification timestamps of the source and intermediate object files, to determine which ones need to be regenerated.)What kind of shitty development tools are you guys used to?

author: maginnovision
author_rank: Super Contributor
timestamp: August 24, 2019, 05:06:14 am
content: Not even Arduino rebuilds unnecessarily.

author: Mechatrommer
author_rank: Super Contributor
timestamp: August 24, 2019, 06:05:43 am
content: if arduino ide which uses gcc/make that is optimized, tell me why it compiled only few hundreds of code lines in minutes? it slowness is like someone who eats cannabis. i believe this is vendor's implementation. anyway i never had issue with my VB/VC, they always compile in like 10 seconds or less on my larger code. its when i tried those free version, i feel like playing with toys.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2019, 07:12:52 am
content: Quote from: Mechatrommer on August 24, 2019, 06:05:43 amThere are no static source files in the Arduino environment, though.You see, Arduino IDE is inherently a code generator. The reason it is slow, is that its design is poor: you cannot determine which intermediate object files need to be recompiled, because the Arduino environment regenerates even the source files every single time! Its slowness has nothing to do with the tools it relies on.If you want an automotive analog, it is like a grandma driving a Porche in reverse down the highway.If you want to see how powerful Makefile-based building can be, look at how the Linux kernel is configured and built. It uses internal C programs to generate the Makefiles, and both gcc and make to keep track of dependencies (make dep). Because the Linux kernel is monolithic, reconfiguring does force a full recompile. However, you can then fully rely on make to compile/build/rebuild the entire kernel, even in parallel (make -jN). If you keep the same configuration, but make changes to some source files, you only need to re-run make to rebuild the kernel; and in most cases, even when your modifications span many files, the recompiles take subsecond times. If you look at the amount of C code involved, the speed at which it does this, is absolutely impressive.The difference between Unix and Microsoft philosophies is that in Unix land, the tools just won't try to stop you from driving like a grandma in reverse; they only exist to do your bidding, not to tell you what to bid on and how and when.

author: Mechatrommer
author_rank: Super Contributor
timestamp: August 24, 2019, 07:58:57 am
content: Quote from: Nominal Animal on August 24, 2019, 07:12:52 amthis thing need highlighting so youngsters will not take other arguments to go against C. i know this fact very well, thats why i keep typing "IDE", not "compiler". C/C++ compiler by itself is an efficient piece of tool made by real man. its just how a programmers or automated tool (IDE) uses it. this is why i suspect this is tools/IDEs specific implementation. AVR Studio 4 that i use, uses similar gcc toolchain (i guess) as Arduino IDE, but compiles at blazing fast speed, well not very fast when intermediate files not existing yet or got deleted, but not that minutes slow time. Arduino IDE is like making the code 10-100X bigger (compared to AVR Studio same code) and compile all in each go, super bloated inefficientagain... IDE tool implementation, not the C. C is number one, backbone for everything else after assembler.

author: maginnovision
author_rank: Super Contributor
timestamp: August 24, 2019, 08:19:31 am
content: I'd agree with the C part, it's pretty much that C++ or xC when I write programs. I've dabbled with python, java, C#, turbo pascal, visual basic and various ASM but I don't think I'm proficient with any of them.The Arduino IDE does store intermediate files in a temporary folder on a per instance basis. When something doesn't need to be recompiled it won't be. Obviously some actions require a full clean and rebuild(changing target MCU for instance, or a new instance of the IDE even if it's the same project open in another instance) and it will do it. I haven't used it in some time but I don't remember it being all that slow. Took longer to reconnect to a Teensy and program than compile a program which had already been compiled even after altering sources.So it is slow the first time, essentially building the entire code base for the target MCU, but after that it works as quickly as you'd expect.

author: Mechatrommer
author_rank: Super Contributor
timestamp: August 24, 2019, 08:33:56 am
content: Quote from: maginnovision on August 24, 2019, 08:19:31 amit doesnt seem so... i did modify my 3d printer marlin fw, that inevitably coded in arduino IDE, changing a single value and recompile will require me to light my "stick" if i dont want to get mad, and wait outside for 5 minutes to relax. 10X changing value in an IDE instance, requires 10 sticks. an abomination.

author: legacy
author_rank: Super Contributor
timestamp: August 24, 2019, 11:02:55 am
content: Turbo Vision! Turbo Pascal OOP! the v7 (for DOS) is still awesome!

author: NorthGuy
author_rank: Super Contributor
timestamp: August 24, 2019, 04:06:43 pm
content: Quote from: Nominal Animal on August 24, 2019, 07:12:52 amSure if you compile one file instead of compiling the whole thing, it's much much faster. However this doesn't mean GCC is fast. if you change something in an *.h file which is included everywhere, you still need to re-compile everything.But this is not the point. The point is that the old Delphi compiler works 100+ times faster than GCC.

author: maginnovision
author_rank: Super Contributor
timestamp: August 24, 2019, 05:49:55 pm
content: Quote from: Mechatrommer on August 24, 2019, 08:33:56 amSo this was a 2nd compile and it still took that long? Perhaps it was a dependency issue, or maybe even a bug(There are a lot of bugs and issues). There are SO MANY stupid things with the Arduino IDE but they made this change at some point to stop rebuilding everything every time and it was mostly appreciated. Even now when I do Arduino based stuff I use the Visual Micro plugin for Visual Studio. It's really beyond frustrating to use the Arduino IDE and possibly the worst way to quickly get through code to debug, make changes, or just figure out where everything is and how it's put together.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 25, 2019, 12:02:24 am
content: Quote from: NorthGuy on August 24, 2019, 04:06:43 pmHow do you compare the speed of compilers compiling completely different programming languages?Isn't that like comparing apples and oranges?

author: CatalinaWOW
author_rank: Super Contributor
timestamp: August 25, 2019, 01:44:08 am
content: Quote from: Nominal Animal on August 25, 2019, 12:02:24 amIt is. But somehow you manage to pick one to eat. The way I did it back in CPM days was that I had Microsoft's compiler package. It had four languages. C, Fortran, Basic and Cobol. I was proficient in Fortran and Algol, ok in Basic and had no clue about Cobol. I had a modest program (something like one or two hundred lines) that I needed for a business project. With the two MS languages I could write in the debug, compile, execute and test cycle took over forty five minutes on the 2 Mhz Z80 machine, with nearly ten minutes being execution cycle. Turbo Pascal came out and the same cycle took about ten minutes. Execution was two and a half, and much of the other 7.5 minutes with my nose in the language description. With those kind of results comparing apples and oranges isn't hard.The key is that you have to evaluate the tools relative to a task or project that you need to do. Different objectives may give different results.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 25, 2019, 02:40:35 am
content: Quote from: CatalinaWOW on August 25, 2019, 01:44:08 amAhem. Care to re-read the comment I commented to, then my comment, and your own? You are restating my own statement, in a comment attempting to rebutt me. Weird. Did you have a point of your own, or did you just want to express your dislike of me via disagreeing?Yes, current versions of GCC use quite a lot of CPU time to compile to machine code, but I would not characterize it asslow.The standard Unix toolchain (make + a compiler) is quiteefficient, as it does not do unnecessary work;and among similarly capable compilers and build systems, GNU make and gcc are surprisingly fast.If you test say gcc 2.95, you'll find that it is much faster than current versions of gcc. This is not because gcc has become worse, but because it spends more time in constructing the best machine code from the same sources than it used to. If you look at the generated machine code, the newer versions do a much better job. (In particular, older versions of gcc were terribly poor at register use, and generated a lot of unnecessary moves between registers. On hardware architectures with few registers, like x86, this meant the old versions generated pretty inefficient machine code.)gcc is not as good as Intel CC when compiling to x86 or AMD64, but then again, gcc can compile the same C code to many different hardware architectures. I personally want AMD64, AVR, and various flavours of ARM Cortex support.The way I defineslowis comparing the time taken to the amount of work done. The Arduino environment is slow, because it does a lot of unnecessary work; and what work it does, it does in inefficient ways.If you consider a build system that only recompiles intermediate object files whose sources or configuration has changed "enterprise grade", when that approach has beenstandardin the unixy world for four decades, you must be bonkers. I consider any build system that does not do that a toy, or a hack. I haven't decided which one I think Arduino is, but I'm leaning towards a cheap hack.

author: Mechatrommer
author_rank: Super Contributor
timestamp: August 25, 2019, 06:36:46 am
content: while some language(s) may compile faster, and perform comparable to C/C++, but in the end, applications that run matters. coding it and running it to make useful works consume the most time in the lifetime. when it comes to language features and capabilities to ease programmers, i'm yet to find a language that can do all in one... pointers, operator overloading etc, type casting to my heart content etc, besides other powerful features (that may be available in another languages too, or may not) such as true OOP, inheritance polymorphism pure abstraction etc... it may not be politically or turingly correct, and it may not have built-in fancy stuffs such as memory boundary check, which it expects the programmers to do by themselves when required (which is its main intention in the first place as low level language as possible and machine independent platform) but who cares? i'm happy enough to have a tool and know that i can do something with it that i cant with another tool. if someone argue a steel hammer may blunt your nail blue if accidentally hit with it, hence use wooden hammer to be foolproof, heck let them use wooden hammer, i will stick with my steel hammer because i know i can hit something hard with it that i cant with wooden hammer. about the blue blunt nail risk, there is workaround for that... be careful and be thoughtful.as to Delphi/Pascal, to me its just a little bit more powerfull than VB in term of GUI development and language features, but VB is more syntax human friendly, and more powerful other features (bell and whistle) such as custom user control creation, and incorparation with VC/C++ DLL at ease, Delphi + Borland C++ gui dev may be able to do as well, but i dont have a chance to know, they made it too difficult to know. so Ms VB + VC combo solved my problem for GUI easiness + speed performance. but that was a long time ago, VB may not be applicable today anymore, Ms stops supporting and making new version of it sad. but what i know is i'm still a C/C++ fanboy, and support for it never diminished. there is hope in term of Windows GUI, even better.. multi platform OS... Qt... thats where i'm heading, if i'm heading at all (i'm getting old, but not yet old)...ymmv.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 25, 2019, 03:56:35 pm
content: Quote from: Nominal Animal on August 25, 2019, 12:02:24 amYou can write a program in C which does something. Then you can write the same in Pascal. It'll be roughly the same amount of code which probably can be easily converted from one to other (most likely even possible with automated C<->Pascal tool). Then you compile one and the other and compare the compilation time.Of course some of the difference will be because Pascal is inherently faster to parse, but most of it would be attributed to the compiler.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 26, 2019, 02:24:09 am
content: Quote from: NorthGuy on August 25, 2019, 03:56:35 pmI recommend you actually do that. Perhaps calculate a small Mandelbrot fractal. Then, measure the compilation and run times for both.You'll be surprised at what the differences are. No, it won't be "pascal 1% of the time gcc takes", not even close. In fact, on non-Windows machines, gcc will typically be faster, and generate faster code.(On x86 and AMD64, as I already mentioned, ICC will be faster than gcc, and generate faster machine code too.)

author: mfro
author_rank: Regular Contributor
timestamp: August 26, 2019, 10:40:54 am
content: Quote from: NorthGuy on August 24, 2019, 04:06:43 pmI'd certainly admit that the Delphi compiler was fast. But not 100 times faster.Comparing GCC (which is not anymore the 'gnu C compiler' but the 'Gnu Compiler Collection' ) to Delphi is comparing apples to oranges. The different language behind it is even the slightest difference between the two (Pascal can't do most of the optimizations C can, so it saves a lot of time with that).Here, GCC is merely a victim of its versatility.First, it follows the good old Unix tradition that working file based saves a lot of memory/allows to compile programs with much less main memory requirements. When Delphi just slurped in the whole source and compiled from memory, gcc reads it line by line and stores intermediate results into temporary files.Then, Delphi supported only one single platform with one single architecture while GCC supports about any platform thinkable. It is usually the very first development tool available if anything new (processor/OS) emerges. GCC also suports many different languages, from Ada to Fortran. To make this possible, it's inner workings are strictly separated. One path analyzes the program for syntactical correctness, another translates it into a synthetical RTL while the next one knows about the specific processor and writes the output as assembly language source that the next pass translates into object files that finally get glued together with the linker.Considering all that, I'd say that gcc is pretty fast for what it does.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 26, 2019, 01:44:32 pm
content: Yeah. Pascal (at least in its original definition) is very easy and fast to parse. And the really fast Pascal compilers of the time (such as Turbo Pascal) were not doing any kind of optimization. Maybe the later versions of Turbo Pascal were (does anyone know for sure?)Delphi (/Object Pascal) was already more complicated to parse and compile, but not that much compared to C++ which is a monster.So there is the language difference, and then the optimizations. To be fair, compare compile times of the same program without any optimization.There is also a difference in the way modularity was handled. When "units" were introduced in Pascal, it was a more efficient way of dealing with modularity and dependencies, since the units interfaces were basically pre-compiled, so that was the equivalent of precompiled headers in C compilers way before they were introduced in C compilers, and even so, I think the interfacing was also much more efficient in itself than even precompiled C headers. So to be fair again here, just compare compile times of sources with minimal or no dependencies.But yes, the grammar of the language and the modularity features made Pascal compilers potentially much faster than C ones in general.As to pure efficiency of the compiler, not considering optimizations and complexity of the language's grammar, sure GCC is not the best out there. Whereas many older Pascal compilers had parsers that were completely hand-written and hand-optimized, GCC used to rely on tools like YACC which are powerful but do not yield the fastest parsers. Apparently, they rewrote the parsers in GCC at some point:https://gcc.gnu.org/wiki/New_C_Parser, I don't know what the current state of things is though, as it has evolved a lot since then. And not all Pascal compilers were fast. Borland ones were, but I think Microsoft Pascal was a dog...

author: NorthGuy
author_rank: Super Contributor
timestamp: August 26, 2019, 02:14:33 pm
content: Quote from: Nominal Animal on August 26, 2019, 02:24:09 amI'm not talking about Pascal, I'm talkng about Delphi compiler. I'm certainly not going to port 300k projects back and forth between C and Pascal to prove it. If you want ballpark, look at this (which I got in my almost 10 year old i5 with Win7):Code:Borland Delphi Version 14.0Copyright (c) 1983,2002 Borland Software Corporation329346 lines, 0.48 seconds, 1340788 bytes code, 2489045 bytes data.Now, get your GCC compiler and compile a 300k project on your favorite PC. See how long it takes.

author: bd139
author_rank: Super Contributor
timestamp: August 26, 2019, 04:09:27 pm
content: Best way to evaluate a programming language, ignoring Jetbrains and taking in reality...1. Hit a job site.2. Find the most expensive thing out there.3. Learn it over a weekend.4. Ponce a job in it by sounding like you know what you're talking about.5. Leverage their mandatory certification scheme.6. Fail to renew the contract.7. Go to 4 (until the fad wears off)8. Go to 1.Problem solved or so I'm told

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 26, 2019, 04:13:41 pm
content: Quote from: NorthGuy on August 26, 2019, 02:14:33 pmYep, good point. We can devise forever about the hows and whys GCC is or is not slower than a typical Pascal compiler, but that's moot when you have concrete examples of typical projects taking infinitely less time to build with one tool than with the other. That's the practical cases that matter for the user, not theory.And I agree you can't get a typical 330kLOC C project to build in 0.48s with GCC even on a killer machine (not saying a supercomputer), and even if you use precompiled headers and stuff and a low level of optimization, or even none.

author: bd139
author_rank: Super Contributor
timestamp: August 26, 2019, 04:19:33 pm
content: Just a point on GCC builds. GCC isn't particularly slow. But people forget that make and decent code organisation is where most of the win is if you want fast builds. Use -j.These stupid projects you see with like 3 C files that are a meg each can go to hell. I've sliced up a few of those before. Mainly because they usually blow the heap on the machine and start swapping like fuck.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 29, 2019, 11:22:02 pm
content: Of course, use proper organization for your builds. And yes, when you do so, GCC is perfectly fast enough.The annoying occasional thing is when you modify a header file that's included almost in all your source files... I try to avoid including headers (except the system headers obviously) in too many source files though. Doing that usually shows poor partitioning of your code.Another situation in which compile speed would matter is for automated builds (which are usually set with a rule of doing COMPLETE builds every time). Often does not matter a lot as the builds are scheduled at night time usually. But hey, some huge C++ projects can take literally HOURS to build... OK that's C++...If you want a C compiler that's really fast, try TCC.https://en.wikipedia.org/wiki/Tiny_C_CompilerIt's blazingly fast. Probably at least 10 times faster than GCC or something. Of course, it does practically no optimization, and I don't know if I'd trust it much compared to GCC. But hey, for those missing the compile speed of Turbo Pascal and the likes, that will get you right back in the same seat.Edit: some real figures to illustrate. Using 'time' and compiling the SQLite "amalgamation", a single C file containing the whole SQLite 3 source code (~7.5 MiB, ~223 kLoC):Code:$ time tcc -c sqlite3.creal 0m0,078suser 0m0,000ssys 0m0,000s$ time gcc -c sqlite3.creal 0m3,448suser 0m0,000ssys 0m0,000s$ time gcc -O3 -c sqlite3.creal 0m23,603suser 0m0,000ssys 0m0,000sOf course the last one with -O3 is not fair (given that TCC has very basic optimizations), that was just to give an idea.Even without optimizations (and granted, GCC still produces better code than TCC), that's a ~x44 factor in speed.It's really lightweight and fast. If you're looking for a small and fast C compiler for a small/old target, I definitely recommend taking a look at it. It's still C99 (and partly C11) compliant!

author: 741
author_rank: Frequent Contributor
timestamp: October 14, 2019, 08:34:17 pm
content: I like Delphi a lot for "PC" programming - a very productive lanuage and IDE. Also, tons of free components out there. Delphi is now v. expensive, so I looked at Lazarus ('free delphi) recently. A variant called Laz4Android seems to be able to cross-compile to 'any' OS, eg palm, Android, Amiga, BeOS, Mac, ...For Lazarus generally, the (Windows) exe files are far larger than Delphi's (to some extent that will be down to cross-platform compatibility, but even when the target is Windows, the exes are large). However I might have missed something as I've only done a fairly small amount with Lazarus. One thing is the debugger is awful, it cannot resolve anything above elementary types. Also some funnies like a different concept of graphical component 'top', 'left' etc, requiring conversion if porting from Delphi (the conversion often fails for unknown reasons).But the big prize is sometning like serial coms on Android, which then communicates with custom hardware. Doing that as far as a compile is not too hard, but I've stalled on the deployment part. For Android, it looks like a main nuisance is how to get the target OS to trust your application.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 14, 2019, 08:36:39 pm
content: Quote from: 741 on October 14, 2019, 08:34:17 pmYou might want to check whether executables contain symbols. That would explain the very large size. If so, there should be an option to strip them.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 15, 2019, 03:10:24 am
content: Quote from: 741 on October 14, 2019, 08:34:17 pmI looked at Free Pascal/Lazarus few years ago. It doesn't come anywhere close to the old Delphi compiler. Typical clumsy open source project.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: December 28, 2019, 12:38:50 am
content: Quote from: ebclr on August 10, 2019, 08:46:29 amWhen Windows came out I tried to get into Visual Studio but found it too hard.A PC magazine had a free copy of Delphi 2.0 on it so I tried that and found it great.In later years Visual Studio improved and became easier to use so I moved over to C# WPF.Then I converted a big program C# to C++ for the extra speed C++ has in Windows graphics.My latest program incarnation is C# .net core 3.1 with winforms and that is very fast with graphics.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 28, 2019, 12:54:01 am
content: Another popular index, TIOBE:https://www.tiobe.com/tiobe-index/places Delphi/Object Pascal at rank 12, which is not that bad.It loses traction for sure, but I think it's not dead yet. One of the big benefits of using Delphi is that you can build native cross-platform apps with the same code base. For sure you can do this with other means, (Java included but Java doesn't quite get you native apps...) If you're not against Object Pascal, it works. I saw they just released a new version, so... Embarcadero is not dead yet.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: February 13, 2020, 02:22:53 am
content: Quote from: Mattjd on June 26, 2019, 10:41:15 amWith C++ you can start reading/writing data outside bounds of arrays unless you use a try catch around the read/write which then causes an exception.I get complete screwed up because i use C++ and C# at the similar times on projects.:: and -> and . often get inter used and errors occur.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 13, 2020, 02:54:18 am
content: One thing I didn't see mentioned in this thread, is how useful it is to use different programming languages for different parts of the same project.For example, I really like writing CPU and I/O-intensive code in C, but use Python for the UI.That way, users and other developers can tweak the UI without having to worry about messing with the C code (assuming a sane interface is used between the two), and I can concentrate on getting it all to work well. (I've said it before, but the best work I've ever done, was in a team with a visually-oriented graphic artist with zero coding experience, and an UX specialist with a bit of scripting experience. We justmeshedwell.)

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 13, 2020, 03:56:06 pm
content: Quote from: Nominal Animal on February 13, 2020, 02:54:18 amI don't like Python personally (which is a detail), but other than that, I fully agree with this.Separating the UI and the core of the application in general is a very sane idea for many reasons including security, reusability and portability. And as you said, it allows completely different people, with even different skillsets, to work on different parts without meddling with one another's part whatsoever.In a couple late designs I've worked on, I have even gone as far as architecturing software so that the core functionalities would run in a separate process and communicate with the GUI through sockets (that way, you can even have remote control, since the GUI doesn't need to run on the same machine!) Can be developed with completely different languages, and naturally enforces full isolation, and perfectly defined interfaces. (May not work when you need really low UI latency, but other than that, works well for a large number of applications.)

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: February 13, 2020, 04:57:03 pm
content: These days I try to do web interfaces for everything.http://thedeviceipand there you go. All that's needed is a bunch of .js and .html text files. XMLHttpRequest works everywhere, and in modern-ish browsers can use WebSockets.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 14, 2020, 12:36:52 am
content: Quote from: SiliconWizard on February 13, 2020, 03:56:06 pmSure; the reason I like Python for this is that it is an interpreter, so the UI code is even end-user modifible without development tools. It has issues, but right now, a Python3 + Qt5 environment is portable across all major and almost all minor OSes, and relatively easily installed on all.Quote from: SiliconWizard on February 13, 2020, 03:56:06 pmI do this extremely often in Linux, using POSIX C for the back end (so not really Linux-specific, but portable in practice across all POSIXy systems). Both for mundane stuff, but also for security sensitive things, with proper privilege separation. Keeping things modular, with well thought-out socket interfaces, makes writing especially security-sensitive code much easier. Better result.In these cases, the design documentation (why the socket interfaces were designed that way) is important to give future developers and maintainers an intuitive grasp of the approach, but it is sadly often omitted. The implementation interface is of course absolutely required, and its specification must be maintained long-term, and only tends to get forgotten if the same developers work on both sides of the interface,or if the developers discuss the interface off-channelwithout documenting the proposed changes and applied changes affecting the interface. (I've been burned by this several times, and refuse to officially discuss API/interface changes except in writing. Otherwise the reality stretches too far from the documentation.)I am still undecided whether documentation should be maintained in separate files, or extracted from the sources (via Doxygen/Sphinx/etc.); or rather, what the balance between the two should really be. Design reports are best separate, I think; and library APIs extracted from sources; but for sockets, and file formats, I am just not decided.Fortunately, all most commonly used programming languages support free-form comments, so that Doxygen/Sphinx/etc. -like generator tools can be used in projects using multiple programming languages.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 14, 2020, 02:02:47 pm
content: Quote from: Nominal Animal on February 14, 2020, 12:36:52 amYeah, that's a very common question/issue, but rarely answered.I see the benefits of documenting things inside the source code itself (so everything is in "one" place, and it shouuld be easier to make code and documentation consistent), but OTOH, it tends to take so much space that code itself becomes difficult to browse. Also, just like regular comments, there's still no guarantee that the comments will match the actual code, even if all is in the same place. Actually, this apparent ease compared to separate documentation makes it easy to just forget about updating the comments IME.My prefered approach so far is to maintain separate documentation, with a clear indication of the exact version of the library/protocol/... it deals with. This way, if you ever modify the source code, the version will change (it should if you work properly!), and won't match the documentation anymore, which forces you to update the documentation itself to keep in sync. It's more effective in practice IME, and has the benefit of "working" without having to actually look at the source code itself. You just need the version numbers, which in any decent worflow, should be correctly updated and maintained without much effort.

author: bd139
author_rank: Super Contributor
timestamp: February 14, 2020, 02:37:18 pm
content: I prefer code generated documentation for API / interfaces and written document for functional notes then structural documentation that ties all the bits together.In heavily componentised distributed systems with limited technical audience it's worth having runbooks for each component aimed at fast architectural and code level understanding.I'm liking Go as a language at the moment for documentation, clarity, performance, workflow, maintainability for commercial delivery. Example package/component documentation:https://godoc.org/github.com/gorilla/websocket

author: schmitt trigger
author_rank: Super Contributor
timestamp: February 14, 2020, 02:53:50 pm
content: Someone has forgotten to include BASIC in the list.Ducking the rotten eggs and running for cover.

author: SilverSolder
author_rank: Super Contributor
timestamp: February 14, 2020, 04:24:39 pm
content: In large companies, it is often hard to get approval for installing a programming environment (e.g. Delphi or whatever).At such times, I have found VBA (Visual Basic for Applications) to be surprisingly powerful and usable... VBA is present in most MS Office products (Excel, Word, ...) and the corporate IT departments are usually forced to permit people to use Office, so you can rely on it always being there!

author: bd139
author_rank: Super Contributor
timestamp: February 14, 2020, 04:26:38 pm
content: Yep at many a company I have used VBA in office to circumvent their "security controls". Remove explorer and run? No worries: Shell "C:\windows\explorer.exe"

author: Bud
author_rank: Super Contributor
timestamp: February 14, 2020, 05:19:32 pm
content: Strictly speaking VBA is a diluted version of VB, it is not as powerful. Good enough for doing Office related stuff but not really application programming.

author: SilverSolder
author_rank: Super Contributor
timestamp: February 14, 2020, 05:25:30 pm
content: Quote from: Bud on February 14, 2020, 05:19:32 pmAgreed, but it is crazy powerful in many ways, e.g. you can launch entire applications and remote control them from a VBA app...

author: Mattjd
author_rank: Regular Contributor
timestamp: February 14, 2020, 07:37:21 pm
content: You guys mean the COM right? Like python has win32com module for that dynamically creates the object definitionsYou can use that to control almost any application on windows that exposes its object library

author: lone wolf1
author_rank: Newbie
timestamp: February 20, 2020, 05:33:23 pm
content: Quote from: nigelwright7557 on February 13, 2020, 02:22:53 amYou can try and access an array outside of it's limits in nearly every language with run-time nasties. The compilers don't do bounds checks as far as I'm aware. It will make it into the run-time. Of course good unit tests would detect it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 20, 2020, 07:36:02 pm
content: Quote from: lone wolf1 on February 20, 2020, 05:33:23 pmIndeed. Whether it is caught at run-time depends on the language and platform, but in any case, this is still a bug that can have nasty consequences, even when the underlying system doesn't allow it to have an effect. If an attempt to access an array outside of its bounds is made, and nothing happens as a consequence - if it's caught - it can still be a problem as to the correctness of the program.Quote from: lone wolf1 on February 20, 2020, 05:33:23 pmDecent compilers can catch out-of-bounds accesses at compile time when they can be inferred statically (from static analysis of the code). Unfortunately, many potential such accesses, apart from the trivial ones, can't be inferred statically.Some high-level languages can mitigate this by forcing developers to use a "range" type for the indices that matches the array being accessed - effectively preventing any possibility of out-of-bounds access by design. You can do this with ADA for instance.Of course you can also implement "safe" buffers in C. This takes extra work that some languages give you for free, but it's a possibility.Quote from: lone wolf1 on February 20, 2020, 05:33:23 pmAnd whatever is done at run-time when it's caught is still completely up to the developer. If you do nothing more than catch it, then it will prevent things like buffer overflows (overwriting the stack for instance), but as I said above, it can still have other consequences than can be just as bad in the end if you don't handle it gracefully - which is often much harder than it seems, so in practice many people just do nothing at all, while being weirdly proud of using such a nice language.As to unit tests, they can only detect what was imagined when they were written. They can never be exhaustive.

author: bd139
author_rank: Super Contributor
timestamp: February 20, 2020, 08:59:29 pm
content: Just a point on all this. While you can write a "safe programming language" and celebrate, it's an order more difficult to write something that is actually safe from a design perspective. I've seen all sorts of things pass through static analysers with flying colours only to walk up to the gate and find it looks like this. The frame and gate are made of the right materials but no one considered anything other than the gate.My favourite was the authentication bypass on a tier 1 bank which was just a case of waiting a couple of minutes for the authentication token to expire. The new one was reissued incorrectly bypassing all authentication.Why bother with the back door when the front door is broken

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 22, 2020, 03:26:16 pm
content: The above picture is a nice illustration for "unit testing".

author: bd139
author_rank: Super Contributor
timestamp: February 22, 2020, 03:38:29 pm
content: Badly done unit testing yes. Which is perhaps 95% of it from experience

author: NorthGuy
author_rank: Super Contributor
timestamp: February 22, 2020, 06:06:35 pm
content: Quote from: bd139 on February 22, 2020, 03:38:29 pmHow's that? This is a perfectly perfect gate. Nothing wrong with the unit. The problem is in the usage.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 22, 2020, 07:48:03 pm
content: Quote from: NorthGuy on February 22, 2020, 06:06:35 pmExactly. This is why I still think this was a perfect illustration of what unit testing can bring you, and what it can't.