Lots and lots of C. (I'm mostly an embedded C programmer these days). Some C++ for a bit of higher-level "business logic" that benefits from a class-based approach, but a fairly limited subset of "modern" C++.
My only real gripe with C is that you have to write your own functions/macros (or use someone else's) to make dealing with strings intuitive. The stdlib is perfectly fine from an algorithmic standpoint, but I always have to look up every string function's manpage, every single time I use them.
Plus if you don't need inheritance, you can just use pointers to structs and pass them to functions. And if you need simple polymorphism in some small places, you can use tagged unions.
This viewpoint is exactly why I like Rust. It has syntactic sugar to make things look like traditional objects, but everything is really a bundle of data with a set of associated static functions. (v-tables only appear with trait objects AFAIK, which are uncommon compared to templates.) And tagged unions are built in, with pattern-matching!
Well, I was using the term a little sarcastically since it is (I think) usually applied to multi-tier web service architectures.
In my case I have an embedded system with a touch screen display, running a bunch of tasks to drive peripherals. There is a task that handles communication with the touch screen (serial). Then there is a set of slow tasks that handles states and modes, for example the runtime representation of a modulator or an RF amplifier. This got extended because we are adding "remote control" support over RS-232 and USB and so this runtime representation has to support more of a multiple model-view-controller. This can be done with queues and a lot of functions but it was simpler to represent it as a tree of stateful values that can be updated via remote commands or via the touch screen and have "downstream" updates. So that's what I mean by the "business logic" -- higher-level than, say, a driver and task for talking to a digital potentiometer or a DAC.
C++ has this weird evolution curve where as you start using features things improve up to a point then go downhill, but then go uphill again with new modern features
If you limit yourself to using the STL with C++11 stuff but don't go crazy with inheritance and templating in your classes it can be nice
Serious question: How does one get into this C embedded stuff?
I'm addicted to low-level "embedded" type work. But all I hear back from are Django, RoR, $HOT_JS_FRAMEWORK, DevOps teams/recruiters.
Is there some buzzword or special topic to know and do a project in? Any suggestions for projects to display on GitHub, topics to know through and through (domain specific knowledge)?
I sit at work thinking all day about RasbPi sensor projects sitting on my workbench collecting dust due to job+young kids.
Look by industry. In the financial sector, knowing VHDL/Verilog is becoming popular (given the rise of FGPAs everwhere). In sectors like robots, defense, aerospace, etc. you'll find a lot of traditional embedded roles.
These aren't "sexy" areas so don't expect to get recruited. Like, mainframe programmers, these positions are in demand but just aren't widely advertised at all.
Search for companies that need to design sophisticated hardware at very low cost. This pretty much guarantees they need to hack microcontrollers, which are usually programmed in C. One I've worked with in my past life as an embedded developer is TI MSP430 (costs pennies), but there's many others.
Another route to code in C close to the hardware is to find work writing Linux kernel device drivers. Of course, you have to know the Linux kernel fairly well in addition to being a good C programmer to land that sort of job. Companies that need this skill include server manufacturers that design their own network interfaces and such, and perhaps phone manufacturers, or companies that design their own SoC's (Qualcomm, TI, etc). Maybe some IoT startups need this skill as well.
Yet another way to code in C is to work in a place that needs to program DSPs. Usually, this also requires knowledge in video/audio engineering. Companies that need this skill design and sell devices that do some sort of video / audio encoding (like video conferencing devices, etc).
I'm sure there's many others I'm not thinking of. I hope this helps...
Being familiar with RTOS's is certainly useful, since there's a decent chance that your future automotive/aero/industrial job uses one.
For a reference of stuff to learn about, go grab the manuals (usually massive) for a recent embedded CPU and see what common topics are foreign to you. Just reading the TOC should prompt some ideas. You may not be applying for one of the lower level "board bring-up" type jobs, but that team will be delivering you libraries that assumes familiarity with IRQs, timers, memory paging, processor modes, DMA, lots of I/O types, etc.
I would get a Teensy 3.2 and start programming bare metal with Arduino. You could also start with Arduino on AVR, but the Teensy gives you a lot more headroom and performance and a very small physical size for very small $.
Arduino is just g++ under the covers, and you can use as much or as little C++ as you want. You can stick to straight C if you like just by not using any C++ features.
Coming from the HFT side, I find C++ surpasses C in a lot of ways for optimization work. Mainly you can use integer template arguments and generic functions to abstract all the boilerplate in a way that is more safe than C macros.
For a semi-contrived example, instead of writing a do4Things() and do8Things() to unwind some loops, I can write template<int> doThings() where the int argument is the bound on the loop.
And having things like a universal template<typename Whatever> toString() that operates on enum classes is nice.
The downside is that it's horribly easy to invoke allocations and copy constructors by forgetting an ampersand somewhere, and the std library isn't well suited to avoiding that behavior either. You have to be vigilant on your timings and occasionally callgrind the whole thing.
Yeah, the nice thing about C++ is that you can generally hide highly optimized portions of code behind nice templates or class interfaces. And with templates you can write libraries that let a lot of compile time logic happen to inline a bunch of stuff and not have to resort to virtual methods.
But when it comes to using things like custom allocators, etc. it's a nightmare. Or a lot of the compile time "traits".
I have a friend who makes a living writing CUDA kernels as C++ templates. His job will be safe for decades to come because noone will be able to decipher the code. :)
Almost didn't read it thinking someone was going Total, LISP Weenie in there. Glad I did: it's a parody of a bunch of languages with some great laughs. Can't even pick a favorite haha. Thanks.
Depends on what you mean by "using". Writing it, probably not so much. But a lot of the numerical things I use are written in Fortran (e.g. BLAS, Atlas). A lot of games I play probably have some hand optimized Assembly. And pretty much everything I touch is in some way backed by C. For natural language processing I've recently (re)discovered how useful PROLOG can be in some cases, and I may touch on that this year.
Not naive at all if you didn't know Amazon, Facebook, and WhatsApp use it? I know a lot of places are starting to use Elixir which runs on the Beam VM. I still think its a safe assumption to ask (why I put a ?).
I guess Whatsapp's purpose is similar to that of telecom though, but that is my naive interpretation of what is done in whatsapp and telecom using Erlang.
- sh (I really don't use bash features in scripting)
- awk
- perl
- sed, if that counts as language.
It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with processing information in ways that involve a lot of repetition and manularity. Scripting solves those things.
(For some things also Excel and VB perhaps counts as an "old" programming language; it is also often quite useful. And I probably will end up doing something in C again this year.)
Too true. When I was 13 or so, I read the DOS 5.0 manual from cover to cover. If I recall, a lot of it was about batch files (autoexec.bat and stuff). Batch was really my first "programming" experience.
Then when I was 22, after a good computer science education, my first job was working at EA, and the build system involved a bunch of batch files. That knowledge from nearly a decade before came in handy! The CS stuff didn't come up until later.
I find that clear notetaking is amazing in guiding discussions. Being the one who sends out the meeting summary with next actions and clarifying remarks or being able to refer back to meeting notes gives me an amazing power in making decisions or resolving disputes. Just because I'm the one who's writing stuff down, I'm somehow given the authority to say "this is what we decided at the meeting".
I am not who you were asking, but I exclusively use pen and paper during meetings. I try to keep my laptop closed and transcribe action items to a personal trello board after the meeting is done.
The trello part is more recent, but I have notebooks going back to my first internship in 2012(which I know isn't that long for most here). It's pretty interesting to see old notes I took and the problems I had at the time.
It varies. I'm often tinkering, which is a problem, I know. I've used a notebook, a Surface pen and One Note, a text file, scribbles on the agenda for the meeting (if there was one). It depends if it's a teleconference or not, whether my laptop battery is charged, if I can find a nice pencil, etc. etc. as well.
The summaries always go out as emails, of course, and if I paper note-take, I try to take a picture and upload it to onenote or sharepoint.
We use a record feature in Zoom for our teleconferences that we want to save, but notes are always better because you can review conclusions without the noise of skipping through discussions. It'd be amazing if there was an application that recorded meetings then summarized them.
I've found that the more attention I pay to my notes, the better I recall the topic at hand even without referring to the notes I've taken.
As a result I exclusively use pen-and-paper for meetings. I also started using fountain pens about two years ago and the discipline required to write well, especially with vintage flexible nib pens, helps keep me focused on note-taking.
I'm not a native English speaker. I could throw in that the best thing regarding learning I did (in addition to buying a home computer) was to get J.R.R. Tolkien's The Hobbit (which came with the adventure game) which in turn led me to read LOTR and then other books in English, and generally become much more fluent.
Later on, wasting time reading NNTP news at the uni was also actually a good investment for learning the language in a way that is useful at work.
For my kids, the games have again been the same thing, along with Harry Potter books.
That's interesting. Whenever my dad wants to become more comfortable with a new language, he reads the translated editions of Harry Potter, too! He's read "Harry Potter and the Philosopher's Stone" in Dutch, French, Arabic, Mandarin, and Spanish, lol.
And the ten minutes striking up a conversation with that strange kid in homeroom sometimes matters more than every other part of high school combined
Wow, that is pretty weird. That was true for me in college. I was at home after graduating in January 2002, at the bottom of the dot com bust. It was hard to find a job then.
I took this world music course in college, and I remember I talked to this guy who was also a computer science major, and he told me he was going to EA. Probably 6 months later, I e-mailed him out of the blue, and that got me the internship which led to my first job.
So instead of all the computer science stuff, I should have just relied on connections from the world music course and on my DOS batch file knowledge from age 13 :)
Very true with perl, although for me it came a bit too late: Larry Wall published first version of Perl at the time of that course, so it obviously wasn't in the content, and I did the stuff with sh, sed and awk, and perl has unfortunately always been a bit of an afterthought for me (I have to look at a manual in some simple things where with awk I don't).
Seriously! I learned so much about scripting and networks in my high school programming classes because a group of us just wanted to play Quake 3 and CS 1.6 instead of doing assignments, and we needed to get around whatever software they had in place to monitor whether you were slacking off.
Any suggestions for a bash scripting tutorial to help me better connect the dots? Over the years I've learned some nifty one-liners, but I'm not really familiar enough with the patterns and art of of command-line thinking to solve my own problems in bash. Most of the bash resources I've found online are just loosely organized collections of magic spells. I'd really like to get better at it though.
[Shameless plug] Not too long ago, I wrote a small book that tries to address those kinds of questions, i.e. how to use Bash to solve problems instead of 1-liners. You may find it useful: http://adventuresindatascience.com
The resource that has been instrumental for me to move up from beginner-that-generally-can-work-out-things-with-a-lot-of-random-tries, to someone who often has things right on the first try, and if not, have a clue of what is going on , has been the following book:
Classic Shell Scripting
Arnold Robbins, Nelson H.F. Beebe
Recommend it to anyone with a basic understanding and a will to learn more. It also really doubles as a rich information resource. Cannot recommend it enough if books are your thing.
I would recommend two things: 1. Read the "bash" man page about once a year, and 2. Learn Perl or Python or something for the harder tasks.
It's helpful to learn some more about bash, and there's some good stuff in there. But shell scripts above a few dozen lines tops are a bad idea, and even those "few dozen" lines need a surprising amount of armoring with "set -e" and such.
I don't think this is because bash is bad. I've come to the conclusion that there's a fundamental tension between interactive use and safe programmatic use, and anything really good at the one is not going to be good at the other. In particular, interactive users more-or-less want the shell to accept inputs that are a bit sloppy, because they can interactively recover from the vast bulk of misinterpretations immediately, whereas a program becomes very risky with the same level of sloppiness because it will quite likely just keep going, doing very bad crazy stuff. (Which is why all my shell scripts tend to start with "set -e", which amounts to "If you get confused... STOP, instead of trashing an arbitrary amount of state.")
And again let me emphasize #1. By splitting my world up into interactive use and programmatic use, I've made my peace with shell, and I don't hate it or anything. I use a lot of the features interactively. For instance, I do a lot of little loops on the command line. Often I'll build them up with some "echo"s done to make sure that it's about to do what I think it will do. There's a lot of great ways to save time in interactive bash (or zsh or whatever), and the best part is, in interactive use you can be as crazy efficient as you want and there are no software engineering implications. Writing bash scripts with every crazy sophisticated trick in the books starts raising software engineering issues fast, and worst of all, some of them are quite invisible ("what if you run this in a directory with a file with a space in it? a newline? a file called '-rf'?"), to say nothing of whether the next person working on the script will know what all the fancy operations do. And I've got a decent-sized collection of 5-line bash scripts lying around doing various things. I just don't let them get much longer.
One of the most useful things to do is just load up an index in your head of what bash can do, then know you can look it up if you ever want it.
(Substitute your choice of shell for bash throughout.)
I'm not proud of it (and I'm not going to share the code) but I wrote a CMS for a medium-traffic site entirely in bash and standard unix tools like awk/grep.
It should be an absolute clusterfuck but it's been surprisingly reliable and performant, to the point where I have no desire to replace it.
If you can't show the code, can you give any info about the overall design of it? I can't even think how you'd structure a "large" application in shell scripts.
This is how many web apps in 1999 ran. As long as you treat your inputs carefully and properly handle file locking, there's nothing inherently bad about that approach.
Projects I know I'll need to heavily modify or work on for the foreseeable future, I bring forward into Lazarus. Lazarus has quite a bit of activity in its community.
Delphi and C++ Builder downfall sadly started when Borland went greedy and started to scare customers with their lack of business focus, specially the spin off.
I think their biggest mistake was trying to follow Microsoft into .Net instead of taking over the native desktop development niche. A native Delphi 8 with some VB6 import tools would have done wonders for them.
Their biggest mistakes were focusing on enterprise life cycle tools, selling the developer tools unit, creating an half hearted port of Delphi to GNU/Linux based on WINE, letting all the key developers leave the company.
All these together created the image that most of us should leave Delphi and C++ Builder while it was still affordable to do so.
I spent time recently in the webcasts for the new version of Delphi, and from what I saw they're doing some good work. The mobile development for example is enticing.
But, and I asked during the webcasts, who's going to buy into a new project now?
For myself I have a couple of old D7 apps for clients that have been running for a decade now.
Sometimes I fantasise about what would've happened if MS had decided, by some fluke, to push, say, OCaml as their big .Net initiative. Can you imagine MS Visual OCaml#? OCaml for Windows app development ... that would've turned some heads.
Exactly, instead of creating a Java clone, what if they'd decided to use a well-understood existing functional language with an elegant module and object system from the very beginning....
Ah, interesting. I used MPW a bit, but far more THINK C and CodeWarrior "back in the day." It is interesting to me that the MPW toolchain would still be useful.
My company has a multi-million-LOC application directed at medium to large healthcare providers written in FreePascal. I have worked with a lot of different codebases, and this is by far the best one. I would like to say it is because I have been the code dictator since it's inception, but it is probably because things are quite easy to structure using pascal.
Delphi/Pascal ran the call center telephony system at a company I worked at, and it ran it well. It was very performant and stable, and ran things for around 14 years.
Spent a while writing and modifying Delphi apps there, I really enjoyed it. I'm actually surprised it isn't used more today, it was definitely "rapid development" at the time.
One thing it was great for was making small, dependency free executables. Similar to today's concept of "Microservices" we often wrote small executable services and applications for tasks and it was very straightforward and simple. You could whip something up in a couple hours that accomplished a lot. Push the .exe file somewhere, add it into the process and forget about it.
Not surprised people are still out there using this stuff.
> I'm actually surprised it isn't used more today,
I'm not at all. Embarcadero has made Delphi a language that is out of reach of the beginner as their Delphi has been rediculously priced. Until recently they didn't have a free Delphi entry level product, it was $199 and was crippled. Now they at least have a free version but the cost has prevented me several times from actually learning Delphi. Now there is FreePascal but Lazarus just seemed clunky and I don't think it has as many bells and whistles as Delphi has.
>I'm not at all. Embarcadero has made Delphi a language that is out of reach of the beginner as their Delphi has been rediculously priced.
Where I live, piracy is casual. People get software for free, and they stopped using Delphi because of Embarcadero. When people don't even deign to pirate your software, something's off.
I think there are many who are still on Delphi 6 which is what I used when I was younger. It was simple, effective, tight. Then that Embarcadero thing came out.
I just think their marketing sucks and their IDE is nowhere near Visual Studio but the price points are nearly the same. Sure you get the VCL and other proprietary things (such as their fireman firemonkey app platform which deploys to android and iOS) but the cross platform tooling for .NET has gotten much better that C# makes more sense for many LOB applications than Delphi does.
One of the companies that works with us in health care projects do all their Windows products in Delphi and AFAIK they don't plan to change anytime soon.
I am working on 20 years old codebase that runs accounting, warehouse management, time tracking, invoicing and whatnot monster that power most of the roofing companies in Austria. It is still Delphi 5 + Paradox, developed on Windows XP (I run it from VM on Mac), but work on modern Windows as well. Networking is a bit of problem, but nothing we can't deal with.
On the other side, I don't think that Delphi/Pascal is dead and I am starting new project this month: control software for laboratory equipment. I can't find any other tool that will let me create multiplatform desktop software that interface directly with hardware. This new software will be written in Lazarus instead of Delphi.
Not unsurprisingly, I'd much recommend getting rid of Paradox. For my projects (several 100KLOCs, most of it DB-related) I relatively easily migrated to Firebird with IBObjects (http://www.ibobjects.com – not affiliated), both of which have been a major success.
Migrating db is on my list all 9 years I am working on project, but I still havent find a way to do it. Core of the problem is stupid idea that paradox tables are actually files, so there are tons of copying and moving files around instead of using paradox as db.
Given the complexity of project and our budget it will have to stay.
I like Delphi. I used to play a lot with both Dephi 7 and VB 6 back when I was in high school. The nice thing about both of them was that they made GUI programming really easy, but Pascal was just a nicer language.
Oddly enough I just got a recruiter spam message for a MUMPS developer position. I had never heard of it, but I thought to myself "why would I want to develop mumps???"
MUMPS get's a bad rep, it's kind of ugly, but has some awesome ideas built into it. I'm not convinced EPIC's success is despite the fact it uses MUMPS, I think it's a contributing factor.
MUMPS is standard in places which deal with Intersystems, via Ensemble (integration system) and their Cache database. An intriguing stack of technologies: an old and 100% backward compatible programming language, an object-oriented (non-relational) database with direct access from the high-level language (M; they do not like it when you call it MUMPS), and quite a number of very good software engineers having worked on this system for 30+ years.
First started programming in MIIS (relative to MUMPS) in late 1981. And have continued to use MUMPS/M/MSM/DSM/Cache for most of the intervening years with 4 years off for Fortran and a year or two for COBOL.
Most of the work has been with medical information systems, although the first job entailed a library information system. One of the few languages I knew of which could make a PC-AT into a multi-user machine. It also enabled a clinic to move from a PDP to a 386 and to no longer have to relegate financial batch jobs to off hours.
Most of my work is in C++, which is almost 35 years old. By far the best choice of language for cross-platform, client application development, especially C++11/C++14, which bring modern language features (e.g. lambdas, futures, etc) with all the original benefits of the language.
I used to write in a pre-11 style. When I got my first job where everyone was using all the hot new features, my mind was blown and my life quality doubled.
Hands down the best thing about C++ for me is that with modern C++ you can write relatively safe clean code while taking advantage of decades of robust libraries.
Yeah, Rust is a big step forward in some respects, but it'll be almost a decade before we see it catch up to C++'s incredible ecosystem. C++ is almost the lingua franca of finance, for instance.
Rust can already take advantage of the C ecosystem quite easily. Rust/C++ usability is a major goal for 2017. I'm hoping that by year end you can have the best of both worlds. The advantages of Rust for new code and the mountain of code that exists for C and for C++.
Well, the C ecosystem has always been easy. The nice thing about C is that generating bindings is a breeze.
I've never been a fan of bindings to C++ libraries. They usually always feel cumbersome and hardly idiomatic. Like it or not, the best way forward is to bite the bullet and slowly natively reimplement the libraries we need in Rust.
I'm starting some work next year on writing some of the basic libraries that someone in the electronic trading world might want to start writing applications in Rust (a FIX/FAST engine and a port of the Aeron message transport). I'm already also writing a native Rust port of our internal consolidated market data library. We already have a Go port along with the C++ code and plan on open sourcing these pretty soon. This stuff tends to be highly proprietary and slow to develop so hopefully we can get some of the more cutting edge users to pitch in and get more people using the language.
C++ FFI will likely be difficult given that unlike C, C++ lacks a stable ABI since the standard doesn't define an ABI, and leaves it up to compilers to implement.
I love that C++ is my primary language right now, after years of being stuck doing Java. I really enjoy working in C++11. With CLion it's super awesome.
CLion really has made C++ fun again. Yeah, there are some bugs you run into here and there with the static analyzer but generally it's fast, really intuitive, and nice to work with.
I once worked at a place that basically just used perl server side. In this decade (2010s). The codebase was just one tangled mess.
They told a story of a guy who failed the cultural interview because he told a VP "you can't write a large web app in perl", and of course they had done just that. With the reflection of hind sight I think despite the obvious empirical counter factual, he was on to something. It really was an uphill battle against the language to do things large scale.
It's not impossible, it's a cultural mismatch. Perl is obscenely permissive, which makes it a really interesting and weird language.
But when you work in a big team and make something complex, you want something that's consistent. All of that permissiveness and flexibility bites you.
Now, with good styling guides and linting, you can make it work for complex software with a big team, but that's culturally pretty anti-perl. We're trying to do that with Javascript now, which isn't as weird as perl, but has many of the same excesses that you want to reign in with a style guide.
In my company we primarily use Perl, but it's just on my team for our ETL pipeline. It works really well, especially since we modernized our older code and enforced really tight code standards. To use Perl end to end, well, there are modules for that (such as Dancer), but I can't comment on them because I've never had to use them.
I recommend Dancer, actually Dancer2 now. So easy to write web apps. Maintainable ones too! Most of the basics of app security are covered within the framework. And where there are gaps (like CSRF tokens), it's trivial to add primitives via DSL.
I tend to answer "can you...?" questions by pointing out that you can do just about anything in any Turing-complete language. The more useful questions are whether you should, and if not, why not. It sounds like an annoying hair-splitting technical distinction, but I've found it leads to more useful discussions.
I think developers have moved on to reinventing Perl in JavaScript. Ever since I saw "use strict"; in a .js file my eyes have not stopped rolling. Personally, I'd choose Perl over JavaScript, Python or Ruby any day of the week but I'd lose all my hipster cred.
Writing a brand new Mac app for myself, using Objective-C instead of Swift. So far it's a breeze. Yes I used Swift for a while, and it sure feels all academic and all, but meh, ObjC gets the job done just fine for me.
Do you have any concerns about maintainability? So far Apple has been advancing Obj-C interfaces along with Swift, but time will probably come when some new OS features will only be available through Swift.
I actually enjoy having separate files for interface and implementation. It's a pain in C++ where you have to put your implementation details (instance variables) in the header, but in ObjC, headers are pretty clean.
I've noticed that my Java-based coworkers often create well-documented interfaces with only a single implementation. They claim to do it for testability, but Mockito can deal with concrete classes as well - I suspect that they secretly enjoy looking at 10 lines of code that describe what a class does :)
I love ObjC, it's the epitome of pragmatism. Fantastic compatibility with C/C++, malleable enough for GUI glue, wonderful libraries (I love NSCalendar & friends).
My clients still accept ObjC for new projects, and they'd be crazy not to, considering how much the Swift 3 migration has cost early adopters.
Given my current pessimism about Apple technologies, I think I'll just milk my ObjC skills until everyone goes Swift-only and then look for work in a portable programming environment.
"classic" asp. Still have some crappy legacy pdf generation code no one is willing to invest the time to rewrite into here. Fortunately that's all of an update a year or so.
Depends on your definition of "old" -- I'm using Bash, PHP, HTML, and JavaScript at work, which are all over 21 years old, but they don't really feel that old (even PHP feels new and shiny thanks to the lovely Symfony framework).
I have no complaints with these languages. I have only seen them used to program PLCs to control machines and processes, and the simplicity of the languages keeps programs simple and straightforward too.
What features are missing that you think belong in process control?
The languages aren't so bad, but the ecosystem is rough. On the PLC vendor side, implementations vary widely and they're all proprietary, so for a given controller... what they give you is all you get. On the programmer side, skills vary widely and ladder logic is the common denominator, so a lot more is written in ladder logic than is appropriate. For instance... Complex sequential logic (like a machine with many adjustable operations, all controlled by an HMI) is difficult to convey clearly in a ladder logic program. It can be done... but all I have ever encountered is lots and lots of spaghetti logic.
I wish I could use sequential function charts to handle some of the complexity in the machines I work on, but the PLC models we use don't even support them. Argh.
I don't think either Go or Rust qualify as "buggy" or "failing." They aren't "old" in my view. And I find Rust more interesting than C or C++ these days. Although C++17 looks nice.
Everyone complains about Asp Classic but as long as I am working on my own code it all works great. I write everything in asp classic about to re-launch a modernized version of my groupware system with a re-design of the display but all of the page logic is all the same.
JS is actually 21 now. According to wiki, it was developed under codename "Mocha" and shipped with Netscape Navigator 2.0. [1] "May 23, 1995" Personally, I'm pretty sure the version of "JS" when it was first released and more modern JS share very little other than logic and symbology, I think that can be said for many programming languages.
I have a feeling that by "old" the topic creator actually meant less relevant than it once was. Both languages are still very relevant and therefore out of the running. PHP may be waning but it still powers a huge chunk of the internet, just think about all those wordpress blogs.
501 comments
[ 3.1 ms ] story [ 344 ms ] threadIn my case I have an embedded system with a touch screen display, running a bunch of tasks to drive peripherals. There is a task that handles communication with the touch screen (serial). Then there is a set of slow tasks that handles states and modes, for example the runtime representation of a modulator or an RF amplifier. This got extended because we are adding "remote control" support over RS-232 and USB and so this runtime representation has to support more of a multiple model-view-controller. This can be done with queues and a lot of functions but it was simpler to represent it as a tree of stateful values that can be updated via remote commands or via the touch screen and have "downstream" updates. So that's what I mean by the "business logic" -- higher-level than, say, a driver and task for talking to a digital potentiometer or a DAC.
If you limit yourself to using the STL with C++11 stuff but don't go crazy with inheritance and templating in your classes it can be nice
I'm addicted to low-level "embedded" type work. But all I hear back from are Django, RoR, $HOT_JS_FRAMEWORK, DevOps teams/recruiters.
Is there some buzzword or special topic to know and do a project in? Any suggestions for projects to display on GitHub, topics to know through and through (domain specific knowledge)?
I sit at work thinking all day about RasbPi sensor projects sitting on my workbench collecting dust due to job+young kids.
These aren't "sexy" areas so don't expect to get recruited. Like, mainframe programmers, these positions are in demand but just aren't widely advertised at all.
Another route to code in C close to the hardware is to find work writing Linux kernel device drivers. Of course, you have to know the Linux kernel fairly well in addition to being a good C programmer to land that sort of job. Companies that need this skill include server manufacturers that design their own network interfaces and such, and perhaps phone manufacturers, or companies that design their own SoC's (Qualcomm, TI, etc). Maybe some IoT startups need this skill as well.
Yet another way to code in C is to work in a place that needs to program DSPs. Usually, this also requires knowledge in video/audio engineering. Companies that need this skill design and sell devices that do some sort of video / audio encoding (like video conferencing devices, etc).
I'm sure there's many others I'm not thinking of. I hope this helps...
For a reference of stuff to learn about, go grab the manuals (usually massive) for a recent embedded CPU and see what common topics are foreign to you. Just reading the TOC should prompt some ideas. You may not be applying for one of the lower level "board bring-up" type jobs, but that team will be delivering you libraries that assumes familiarity with IRQs, timers, memory paging, processor modes, DMA, lots of I/O types, etc.
Arduino is just g++ under the covers, and you can use as much or as little C++ as you want. You can stick to straight C if you like just by not using any C++ features.
For a semi-contrived example, instead of writing a do4Things() and do8Things() to unwind some loops, I can write template<int> doThings() where the int argument is the bound on the loop.
And having things like a universal template<typename Whatever> toString() that operates on enum classes is nice.
The downside is that it's horribly easy to invoke allocations and copy constructors by forgetting an ampersand somewhere, and the std library isn't well suited to avoiding that behavior either. You have to be vigilant on your timings and occasionally callgrind the whole thing.
The other downside is that your colleagues are more likely to "knit a castle" with ridiculous class hierarchies or over-generalization. ( https://www.infoq.com/presentations/Simple-Made-Easy )
But when it comes to using things like custom allocators, etc. it's a nightmare. Or a lot of the compile time "traits".
EDIT: Removed the "naive" part.
- awk
- perl
- sed, if that counts as language.
It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with processing information in ways that involve a lot of repetition and manularity. Scripting solves those things.
(For some things also Excel and VB perhaps counts as an "old" programming language; it is also often quite useful. And I probably will end up doing something in C again this year.)
Then when I was 22, after a good computer science education, my first job was working at EA, and the build system involved a bunch of batch files. That knowledge from nearly a decade before came in handy! The CS stuff didn't come up until later.
I myself have found out that during meetings I prefer to use a pen and paper but it is mostly just notes that I take for myself.
The trello part is more recent, but I have notebooks going back to my first internship in 2012(which I know isn't that long for most here). It's pretty interesting to see old notes I took and the problems I had at the time.
The summaries always go out as emails, of course, and if I paper note-take, I try to take a picture and upload it to onenote or sharepoint.
As a result I exclusively use pen-and-paper for meetings. I also started using fountain pens about two years ago and the discipline required to write well, especially with vintage flexible nib pens, helps keep me focused on note-taking.
Later on, wasting time reading NNTP news at the uni was also actually a good investment for learning the language in a way that is useful at work.
For my kids, the games have again been the same thing, along with Harry Potter books.
Wow, that is pretty weird. That was true for me in college. I was at home after graduating in January 2002, at the bottom of the dot com bust. It was hard to find a job then.
I took this world music course in college, and I remember I talked to this guy who was also a computer science major, and he told me he was going to EA. Probably 6 months later, I e-mailed him out of the blue, and that got me the internship which led to my first job.
So instead of all the computer science stuff, I should have just relied on connections from the world music course and on my DOS batch file knowledge from age 13 :)
QBasic was nice, but no-where near as all-encompassing as touch-typing.
I don't have a formal place for reviews but I posted about it on HN previously and the response seemed positive: https://news.ycombinator.com/item?id=10112615.
Also, you can enter "hackernews" to get 25% off
And goes on from there ;)
Classic Shell Scripting Arnold Robbins, Nelson H.F. Beebe
Recommend it to anyone with a basic understanding and a will to learn more. It also really doubles as a rich information resource. Cannot recommend it enough if books are your thing.
It's helpful to learn some more about bash, and there's some good stuff in there. But shell scripts above a few dozen lines tops are a bad idea, and even those "few dozen" lines need a surprising amount of armoring with "set -e" and such.
I don't think this is because bash is bad. I've come to the conclusion that there's a fundamental tension between interactive use and safe programmatic use, and anything really good at the one is not going to be good at the other. In particular, interactive users more-or-less want the shell to accept inputs that are a bit sloppy, because they can interactively recover from the vast bulk of misinterpretations immediately, whereas a program becomes very risky with the same level of sloppiness because it will quite likely just keep going, doing very bad crazy stuff. (Which is why all my shell scripts tend to start with "set -e", which amounts to "If you get confused... STOP, instead of trashing an arbitrary amount of state.")
And again let me emphasize #1. By splitting my world up into interactive use and programmatic use, I've made my peace with shell, and I don't hate it or anything. I use a lot of the features interactively. For instance, I do a lot of little loops on the command line. Often I'll build them up with some "echo"s done to make sure that it's about to do what I think it will do. There's a lot of great ways to save time in interactive bash (or zsh or whatever), and the best part is, in interactive use you can be as crazy efficient as you want and there are no software engineering implications. Writing bash scripts with every crazy sophisticated trick in the books starts raising software engineering issues fast, and worst of all, some of them are quite invisible ("what if you run this in a directory with a file with a space in it? a newline? a file called '-rf'?"), to say nothing of whether the next person working on the script will know what all the fancy operations do. And I've got a decent-sized collection of 5-line bash scripts lying around doing various things. I just don't let them get much longer.
One of the most useful things to do is just load up an index in your head of what bash can do, then know you can look it up if you ever want it.
(Substitute your choice of shell for bash throughout.)
It should be an absolute clusterfuck but it's been surprisingly reliable and performant, to the point where I have no desire to replace it.
Before there was an internet of lightbulbs and smoke detectors, there was an internet of industrial process things.
And they used windows 2000 and Delphi. They still do.
I really like Delphi actually. It's a shame Embarcadero doesn't really seem to care about it.
I keep spending tons of time fighting problems, even with mainstream libraries like sqlite.
Still the best tool for multiplatform desktop apps development.
Their biggest mistakes were focusing on enterprise life cycle tools, selling the developer tools unit, creating an half hearted port of Delphi to GNU/Linux based on WINE, letting all the key developers leave the company.
All these together created the image that most of us should leave Delphi and C++ Builder while it was still affordable to do so.
But, and I asked during the webcasts, who's going to buy into a new project now?
For myself I have a couple of old D7 apps for clients that have been running for a decade now.
Hahaha. That was good.
Delphi is used heavily at my company to process millions of transactions a day, in the credit card industry.
I myself am a C# developer though. But I respect Delphi's performance and relatively clean syntax.
Now we kind of got .NET Native, but it still isn't 100% done.
Hahaha. That was good.
Delphi is used heavily at my company to process millions of transactions a day, in the credit card industry.
I myself am a C# developer though. But I respect Delphi's performance and relatively clean syntax.
You're deploying on 68K Macs?
https://github.com/ksherlock/mpw
Here's the end of a Makefile, very unix-like:
Spent a while writing and modifying Delphi apps there, I really enjoyed it. I'm actually surprised it isn't used more today, it was definitely "rapid development" at the time.
One thing it was great for was making small, dependency free executables. Similar to today's concept of "Microservices" we often wrote small executable services and applications for tasks and it was very straightforward and simple. You could whip something up in a couple hours that accomplished a lot. Push the .exe file somewhere, add it into the process and forget about it.
Not surprised people are still out there using this stuff.
I'm not at all. Embarcadero has made Delphi a language that is out of reach of the beginner as their Delphi has been rediculously priced. Until recently they didn't have a free Delphi entry level product, it was $199 and was crippled. Now they at least have a free version but the cost has prevented me several times from actually learning Delphi. Now there is FreePascal but Lazarus just seemed clunky and I don't think it has as many bells and whistles as Delphi has.
Where I live, piracy is casual. People get software for free, and they stopped using Delphi because of Embarcadero. When people don't even deign to pirate your software, something's off.
I think there are many who are still on Delphi 6 which is what I used when I was younger. It was simple, effective, tight. Then that Embarcadero thing came out.
On the other side, I don't think that Delphi/Pascal is dead and I am starting new project this month: control software for laboratory equipment. I can't find any other tool that will let me create multiplatform desktop software that interface directly with hardware. This new software will be written in Lazarus instead of Delphi.
Given the complexity of project and our budget it will have to stay.
To be honest I am not sure if the founding developer was crazy genius or just crazy.
My only problem is that I have to maintain legacy codebases without OOP code.
Ha ha, good one.
There was this interesting thread on Delphi a while ago on HN:
Delphi – why won't it die? (2013 (stevepeacocke.blogspot.com)
https://news.ycombinator.com/item?id=7613543
[1] https://en.wikipedia.org/wiki/C_Sharp_(programming_language)...
Generics came with C# 2.0 in November 2005 (12 years old)
LINQ came with C# 3.0 in November 2007 (9 years old)
http://thedailywtf.com/articles/A_Case_of_the_MUMPS
http://thedailywtf.com/articles/MUMPS-Madness
Most of the work has been with medical information systems, although the first job entailed a library information system. One of the few languages I knew of which could make a PC-AT into a multi-user machine. It also enabled a clinic to move from a PDP to a 386 and to no longer have to relegate financial batch jobs to off hours.
Will probably also continue to use AWK this year.
Yeah, Rust is a big step forward in some respects, but it'll be almost a decade before we see it catch up to C++'s incredible ecosystem. C++ is almost the lingua franca of finance, for instance.
I've never been a fan of bindings to C++ libraries. They usually always feel cumbersome and hardly idiomatic. Like it or not, the best way forward is to bite the bullet and slowly natively reimplement the libraries we need in Rust.
I'm starting some work next year on writing some of the basic libraries that someone in the electronic trading world might want to start writing applications in Rust (a FIX/FAST engine and a port of the Aeron message transport). I'm already also writing a native Rust port of our internal consolidated market data library. We already have a Go port along with the C++ code and plan on open sourcing these pretty soon. This stuff tends to be highly proprietary and slow to develop so hopefully we can get some of the more cutting edge users to pitch in and get more people using the language.
Java is in the same boat, but at least it's still marketable so engineers don't mind working with it as much.
They told a story of a guy who failed the cultural interview because he told a VP "you can't write a large web app in perl", and of course they had done just that. With the reflection of hind sight I think despite the obvious empirical counter factual, he was on to something. It really was an uphill battle against the language to do things large scale.
But when you work in a big team and make something complex, you want something that's consistent. All of that permissiveness and flexibility bites you.
Now, with good styling guides and linting, you can make it work for complex software with a big team, but that's culturally pretty anti-perl. We're trying to do that with Javascript now, which isn't as weird as perl, but has many of the same excesses that you want to reign in with a style guide.
I use Perl to manage such a monster.
I've noticed that my Java-based coworkers often create well-documented interfaces with only a single implementation. They claim to do it for testability, but Mockito can deal with concrete classes as well - I suspect that they secretly enjoy looking at 10 lines of code that describe what a class does :)
My clients still accept ObjC for new projects, and they'd be crazy not to, considering how much the Swift 3 migration has cost early adopters.
Given my current pessimism about Apple technologies, I think I'll just milk my ObjC skills until everyone goes Swift-only and then look for work in a portable programming environment.
https://en.wikipedia.org/wiki/IEC_61131-3
What features are missing that you think belong in process control?
I wish I could use sequential function charts to handle some of the complexity in the machines I work on, but the PLC models we use don't even support them. Argh.
VBScript
JScript
Those aren't old enough to count, I guess
googles age of PHP
Holy crap! PHP is almost 23 years old. Probably still not considered "old" though...
[1] - https://en.wikipedia.org/wiki/JavaScript