Ask HN: What “old” programming languages will you still be using in 2017?
And what is the purpose?
I'm still using bash, awk, and a bit of FORTRAN for scientific computing.
I'm still using bash, awk, and a bit of FORTRAN for scientific computing.
I have been using it professionally for 5+ years as a full-time employee at various companies. Some big-name ones, some smaller start-up ones. The mean Lisp team size has been around 4, but I did work on a project of 15 Lisp programmers. None of these projects were legacy code. Some were in places you wouldn't expect (embedded, multi-processor systems on custom-designed boards, for example). In every single case, we had no additional trouble hiring a Lisp or Lisp-capable programmer as compared to hiring for any other language, including Python. (In fact, Python was more difficult to hire for because the market is saturated with beginners who claim expertise.)
Lisp is one of those languages where the ratio of long-term benefits and productivity vs. good initial impressions is at a record high. It doesn't look like C or Python or JS, with all the parentheses, so people brush it off.
Lisp isn't the pinnacle of every great idea to come about in computer science and software engineering, but it is one of the most robust, macroscopically well designed, and most productive languages for translating arbitrary abstract ideas into maintainable, production code. Even if it doesn't look initially very pretty in the eyes of a career Python programmer.
Doesn't that imply an over-supply?
I did my grad research on a highly specialized topic, involving plenty of math/physics.
Then I worked in industry applying my skills for 4 years.
Then I switched to programming - nothing related to my engineering degrees. This job requires only a BS (and not really that - one of my coworkers has no degree).
The highly specialized job was the one where I had little leverage, lower pay, and a miserable experience. Why? Fewer jobs than supply.
Whereas for programming, the supply is much larger than for the specialized work, but the demand is even larger than the supply.
The geek in me yearns for a job where I can go back to numerical algorithms and physics. But frankly, those jobs tend to suck when you don't have much leverage.
There are fewer pure research positions, and unless you are very good there is a leverage problem there because every year dozens of new grads come looking for essentially that job. Something to bear in mind if your desire is primarily to work in matlab/python/R on things that look a bit like your thesis did.
With that said, though, and especially with huge companies like Google using Python as one of their main languages, the supply of qualified Python programmers is no doubt larger than that of Lisp. But, it's a fallacy to believe that the supply of qualified programmers correlates inversely to the time spent searching for them. It's sometimes easier to find needles that standout in the haystack.
As for software jobs in the domain of math/physics/etc., they're out there, but just harder to seek out. The world hasn't run out of hard science problems to solve, and many companies would go to great lengths to hire brilliant individuals who have both scientific acumen and programming skills.
I'm well aware of that. However, my experience is the working conditions are poor. Some do have a higher salary, but everything else seemed worse.
Also, not entirely related, but it does suck more when you're working on a very challenging problem, and can't fully crack it on the company's desired schedule. You get negative feedback with veiled threats about losing your job. When you're in that situation, and realize that you can get a much easier job with similar pay, you have to ask yourself whether the risk of working a "science" job is worth the rewards.
It was all fun in grad school, where the deadlines were much looser and you're not worrying about saving for family, retirement, etc. But it really sucks if your livelihood is at stake merely because you wanted the thrill of working on a more challenging problem.
Yes, might take a little time to get your Github up to speed with samples in a different language and employers intelligent enough to see past "X years in Y language" requirements, but I think it will be an easier shift than numerical algorithms and physics to programming, I think.
The one exception is maybe Clojure, but I find Common Lisp to be all around better at the problems I've worked on (namely ones where at some point or another, a native machine code compiler is required). Clojure' async/immutability story seems good for larger distributed systems, though, and interoperation with Java is invaluable to some projects. (Though, Common Lisp does have an implementation atop the JVM, called Armed Bear Common Lisp. This is one of the many benefits of an official language standard.) But by using Clojure you are definitely locking yourself into a single implementation.
Googling, LinkedIn searching helps.
- 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.)
${VAR:INDEX}
${VAR/PATTERN}
${VAR#PATTERN}
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.
I soon ported the project over to use Postgres and decided that actually SQL is awesome.
Both kinds of work are hard, but with SQL you can usually expect the problem to yield to intense engagement and produce a solution that's complete, robust, and satisfying.
But in a classic meme sense: "It isn't you I hate SQL, it's what I have to think about when I use you." I don't want to spend my time thinking about database indexes, query plans, or other complicated bits. I just want to get my data out.
Sometimes I struggle, and I'd give anything for a plain inner join, but on the whole I like this tradeoff.
What do you find simpler in terms of data querying and management?
Pandas is an excellent contribution to data analysis, but I gotta tell you, I was absolutely delighted to learn about pandasql and realize I could write selects, group by, order by, and so forth, converting data frame to data frame through sql.
What can I say? I truly encourage people to give SQL a real chance. I'm happy to use ORMs that save me some typing on simple queries, and certainly I use a combination of pandas and sql, there are some things much better accomplished through a programming language. But I'm willing to drop to SQL pretty quickly if I sense that the programming language or library is really just forcing me to re-learn a new implementation of sql.
the concept of a query really seemed odd, it took some mental adjusting. My only programming background was largely in writing procedural code. My brain really wanted to think in terms of methods, functions, inputs, and return values.
It's been so long (18 years since that course), that it is difficult to remember the mindset I was in. It all seems pretty natural now. But you are absolutely right, you do need to start thinking in terms of sets and operations on sets, not in terms of methods with inputs, procedures, and return values
I eventually moved from Access to MySQL/SQLite, but if it weren't for Access's interactive query designer, where the tables are presented as lists of columns and you draw/drag lines to declare a JOIN between columns [1], I honestly don't think I would have ever grokked SQL.
I actually think that without SQL, I would have never understood the power and purpose of a JOIN, even though that concept of comparing lists is the foundation of most investigative research. So I justify forcing SQL on to journalism students not merely because it's a useful skill, but because it presents the best vocabulary and grammar for describing the idea of joins.
Also, SQL's general lack of data-munging functions or conveniences really drives home that data is just characters and numbers, and doesn't magically have meaning or come into existence. That is an extremely difficult concept to convey with Excel -- e.g. how it automagically converts `9-11` into `11-Sep` and confers a datetime context onto what was just plaintext.
[0] http://www.cde.ca.gov/ds/dd/
[1] http://www.opengatesw.net/ms-access-tutorials/Access-Article...
It also should integrate easier with other languages. Using SQL from C# or C++ is a real pain with tons of casts and string manipulation. Better debugging would also be nice.
I think it looks a lot like COBOL :)
Which isn't surprising given it was designed by IBM in the 1970s.
I'm grateful that it doesn't look like other languages. The format it uses is really easy to generate using other languages, which makes it really useful in a lot of what I do.
A SQL like language in JavaScript is Mongo shell, which is much more complex that SQL. Every time I use it I wish they adapted SQL to Mongo instead of writing their own thing. I usually end up writing complex queries in Ruby with Mongoid. They're more compact and easier to understand.
About ActiveRecord/AREL vs SQL, they're more or less the same. Sometimes a query is easier to understand in Ruby, sometimes in SQL. Complex queries are much easier to read in SQL or outright impossible to code in Ruby.
If I could change something about SQL I'd change all the arbitrary weirdnesses of the data definition language and the non orthogonal stuff, like HAVING which is a WHERE in a different context (aggregations vs rows).
A re-design might be nice for programmers, but would likely lock out most people with no programming backgrounds who work on databases.
Since Javascript is the best programming language ever (so I hear :-) ) maybe using Javascript syntax and objects would be nice.
Like the FireFox SQLite Manager plugin, it's cross-platform and free and fairly easy for anyone to install. DB Browser's interface is substantially cleaner than the Firefox plugin, though, and the devs are responsive on Github.
DB Browser is great, all things considered, but I've never found a GUI that didn't overcomplicate the kinds of simple interactions I want when teaching databases (i.e. 99% of what I teach are SELECT queries). It also makes a few concessions in order to appeal to the Excel crowd. For example, not committing writes to the database until you do a Cmd-S...which contradicts what I tell my students about how SQL gives you more responsibility through explicit and consistent behavior (e.g. when you delete a row, it's gone forever...so don't ever delete things unless you really need to). On the other hand, some of the concessions are nice, such as the ability to rename columns via the GUI, which is not part of the SQLite spec.
So I have contemplated teaching SQL from the command line. But I've had a hard time imagining how the steep learning curve could justify the potential advantages for the average novice.
Here's a page I wrote up for students on how to install SQLite browser: http://2015.padjo.org/tutorials/sql-admin/getting-started-wi...
For comparison, here's my instructions for FF's SQLite Manager Plugin: http://fall2014.padjo.org/tutorials/databases/getting-around...
(that page also includes how to work with Sequel Pro and MySQL; I soon realized that giving students two choices for learning SQL was a very bad idea and have since stuck to SQLite)
Here's a take-home midterm: http://2015.padjo.org/assignments/midterm-wsj-medicare-walkt...
I've found it better to provide pre-packaged databases for students and basically ignore the administrative part of SQL and databases -- e.g. importing of data, defining a schema, creating indexes, etc. -- until we've learned all we can about working with SELECT and JOIN: http://2016.padjo.org/tutorials/sqlite-data-starterpacks/
It's not SQL I dislike, it's that it means I'm using a database, and I've lost more of my life than I care to admit to in planning, designing, and maintaining databases so that they perform under production pressures.
> It isn't you I hate SQL, it's what I have to think about when I use you.
Do you live at the fringe of performance like that? Nobody spends much time thinking about those things, and the few times that require thinking about them would require thinking about much more complicated things if you weren't using a database.
If I'm building a simple CRUD app, then I don't need the complexity that SQL provides. If I'm building something bigger, then I probably need to think about the query plans.
I would have loved a tool that I could hand a proposed schema, estimates of the data, and some SQL I want to run that would come back and tell me "That's stupid, because you're doing a join on computed data; add this index, denormalize this field, and remove this clause from your query." but I'm also realistic enough to know that such a tool isn't plausible.
https://technet.microsoft.com/en-us/library/ms176005(v=sql.1...
Postgres has explain and some third parties make query tuners.
Oracle has a host of third party tunes, Solar Winds being the first that comes to mind.
I don't know if any of these can do it off a proposed schema but you could create a dummy database and your insert/read routines run a script against it to simulate transactions and run the capture on these tools and they will explain the recommended adjustments. Some of them like MMSQL query tuner will export a script that can make the adjustments.
The biggest thing for DB performance for most CRUD applications is to ensure you eliminate table spools on joins. If you find all of those you are ahead of the game in most instances.
Why should I have to know what a table spool is and why they're bad?
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.
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".
Implementing something like modem initialization - "Send AT command to modem/wait for a reply matching one of several patterns or a timeout/handle result/rinse, lather, repeat until done" - is quite trivial to do with expect.
It's not something I use every day, but it's one of those useful things to keep in your mental toolbox.
I've been using it for 15 years to automate network configuration deployment. Now that automation is all the rage in the industry it gets dismissed, but I find it is often much better than some of the other tools available.
It can read/write stdin/stdout (just as any scripting language can) so it can be used to write additional filters/tools that don't exist in the standard set that can then be used from shell as with any other tool.
But if you mean using it to create a pipeline out of existing command line tools, then yes, but with a bit more boilerplate than plain shell needs. The built in "exec" command has an almost shell syntax for starting pipelines, and the "open" command supports the same syntax, so it is 98% "as well" in that regard. But to avoid getting stuck in a deadlock trying to write data to a pipeline that is returning filtered data to the script requires turning on Tcl's event driven file IO, which is where the extra boilerplate comes from.
I meant roughly all that can be done with shell, except maybe somewhat differently (due to Tcl's different syntax or features). The usual things: call existing command-line tools, write scripts in which you use its own syntax/features as well as call / pipe between / orchestrate command line tools, redirect std I/O, etc. - the things that make the shell powerful.
Thanks for the reply. Seems like it is close to equivalent from what you say.
The subject is "tcl pipes".
https://www.google.com/search?q=tcl+pipes
and this second result was interesting:
It compares doing the same task (getting a part of a string from the last line of a text file) in Tcl and Python. Seems to conclude that some things are easier in Tcl and some in Python (based on a quick read).
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.
C for (embedded(embedded))* audio DSP engine, with hardware specific intrinsics and occasional drops into inline ASM when those fail. When every cycle counts and Hard Real Time contracts must be met, to me it is anathema for any invisible compiler-generated code to exist - such breaks the required determinism. So no C++. Would write in pure ASM in the old days. Still want to - most times the C preamble/postamble is not needed in event handler functions. But TPTB dictate otherwise. Small talent pool and they want Jr progs to take it over.
FORTH as the most useful interactive hardware/low level software debugging tool for behavioral debugging (vs post mortem breakpoint debugging, which loses the behavioral context). Used to use hardware logic analysers for this but system complexity out-grew them. I should note I am not using a commercial FORTH, rather a freeware core greatly extended and modified by me for this purpose. Used it in several projects with different CPUs and architectures over the years. Can feed it C headers for readable dumps too (translator written in PERL). Key point: does this while the target continues executing. Caveat: do NOT use unless you know and understand every line of code in the engine and its implications for the target system. Given that, it's the sharpest double-edged handle-less debugging tool I've ever found.
* the DSP engine is embedded inside a larger embedded system. All inside the same chip. Makes for interesting times when one cannot touch it directly in main OS land.
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.
You're deploying on 68K Macs?
https://github.com/ksherlock/mpw
Here's the end of a Makefile, very unix-like:
APPL = ${TYPE}${NAME}
DATA = DATA${NAME}
OBJS = ${NAME}.p.o
LIBS = ../WordSum.asm.o ../LASysLib.a.o ../PasLib.o
LANG = C
MPWC = /usr/local/bin/mpw
AS = Asm
AFLAGS =
CC = SC
CFLAGS = -mc68020 -mc68881 -b2 -Opt all
PC = Pascal
PFLAGS = -mc68020 -mc68881
LD = Link
LDFLAGS = -w -t LApp -c MPWX -m MAIN -sg ${NAME}
# Link -w -t TEXT -c RWG1 -rt CODE -m HELPLOOP -sg HELPLOOP
CFMFLAGS =
# CFM = ${MPW:/mpw=/cfm}
# CFM = /usr/local/bin/cfm
CFM = cfm
# TFTPFLAGS = -vt
TFTPFLAGS =
# TFTP = ${MPW:/mpw=/tftptool}
# TFTP = /usr/local/bin/tftptool
TFTP = tftptool
.SUFFIXES : .p.o .p .c.o .c .asm.o .asm
.phoney : all clean install
all : ${APPL} ${DATA}
.asm.asm.o :
${MPWC} $(MPWFLAGS) $(AS) $(AFLAGS) $<
.c.c.o :
${MPWC} $(MPWFLAGS) $(CC) $(CFLAGS) $<
.p.p.o :
${MPWC} $(MPWFLAGS) $(PC) $(PFLAGS) -r $<
${NAME} : ${OBJS} ${LIBS}
$(MPWC) $(MPWFLAGS) $(LD) $(LDFLAGS) ${OBJS} ${LIBS} \
-o $@
${APPL} : ${NAME}
$(CFM) $(CFMFLAGS) $< $@
mult.asm : mult.py
./mult.py >mult.asm
mult : mult.asm.o
$(MPWC) $(MPWFLAGS) $(LD) $(LDFLAGS) $< -o $@
${DATA} : mult
$(CFM) $(CFMFLAGS) $< $@
# send DATAFILE first
install : ${APPL} ${DATA}
$(TFTP) $(TFTPFLAGS) ${NODE} ${DATA}
$(TFTP) $(TFTPFLAGS) ${NODE} $<
clean :
$(RM) -f ${TYPE}${NAME} ${NAME} ${OBJS}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)
It first appeared in 1984 and the ANSI specification was finished in 1994, but it traces its lineage directly back to Lisp 1.5 from 1962. It can run Lisp sources decades older than it trivially.
It is a very practical, multi-paradigm language with high quality, high performance implementations on many platforms.
Its main issue is that it is not very popular, but that might also be a blessing.
Python for when someone needs me to work on Django, and also for helping my younger daughter learn programming, because it's a pretty accessible place to start.
C when I need to be that close to the machine and there's some reason not to use Lisp.
assembler (various) (I've even learned x86_64 well after being a RISC aficionado, it's actually kinda neat)
sed
bash
LaTex
I used to use YACC/LEX but that's been replaced with ANTLR for awhile now.
What language am I starting to use? Rust and R.
I wrote something in PERL once but when I woke up the next day I couldn't really read it. So that was that.
for OP: Perl is a rich and deep language. It's as or more comptetent as exactly the same things as ruby and python (although pythons maths, and keeping management happy libraries are better, perl's async and systems wrangling )support is better. It is more permissive than you would want in some circumstances, but in my experiencing running a competent perl team with supportive management is a pleasure.
It really hits a sweet spot for me:
- fast executables
- fast compile times
- very expressive
- good standard library in 'Core'
- a REPL so you can easily play around with code you have just written
- a type system that's really useful for catching bugs
- imperative programming is relatively easy
I find myself becoming more and more productive. I will have to see if writing a little server for JSON web API sitting behind nginx is feasible - currently using ruby for that.
Secretly, it's just fortran all the way down, and LaTeX for document preparation.
Piled on top of that is a fair amount of matlab, simulink, and python.
It took me about a week to find out that the author of a model i worked on didn't know about `from copy import copy`, which explains a great deal about why their ODE solver wasn't working.
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.
Django was a bit more beginner friendly for someone new to a framework, and the documentation is really good. And the Django admin is one of the best ways to get something up and running quickly, there wasn't a Perl equivalent when I was trying Catalyst.
I'm in the process of "inheriting" a company whose sole product is a multi million LOC behemoth written in Delphi. The product itself is a highly customizeble/parametrizeable control software for business processes/alarm management build around a rule engine for rules drawn in a graphic editor.
On the plus side, Delphi is quite easy to read. I got started with no prior knowledge in Delphi or Pascal, and I was able to roughly understand significant parts of the application within a few days.
Also, some work in MPASM (Assembly for the Microchip PIC series of microcontrollers - same reason)
Edit: I am not sure just when S5 got introduced, but I've got installation media - on 5.25" floppies - for CP/M in my office. Made in West Germany.
That old.
Luckily, the IDE has also been ported to more contemporary operating systems.
I started using Clipper in 1986 and some of 1986 code still runs today. Clipper was a compiler for Ashton tate dbase II language.
Harbour now allows to run old code on windows, linux, Mac, Solaris and a bunch of other less common OSes, both in text mode or using some gui lib. It will also run on android and ios (using Qt).
Blast from the past.
Also, the floppies got wiped out on the way to the big demo, 'cause the backpack was up against the car speakers in the back seat on the way there). Maybe '91.
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.
It's an awesome language and both the language and the ecosystem is getting better and better all the time
Also, I have written a couple of reporting scripts to watch over our Active Directory (look for computers that do not exist any more but still have their AD accounts, stuff like that).
Oh yeah, and a couple of Nagios plugins, too.
For these tasks, there are not many languages that can match Perl in versatility and productivity. It's not the prettiest language, but it's extremely useful.
Beyond that I use it for microservices, implement REST-APIs, and also for powering whole sites. With the right framework/modules you can do almost anything.
For example I re-implemented the API my home lights use to communicate, allowing me to use cron to turn off lights via the perl interface.
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...
I do as much in Python as I can justify, but I still have to work in VFP quite a bit. I personally have code from 1988 that's still running in this application.
Sigh...
But, I'll give FoxPro one plus, it can integrate quite well with REST APIs. Hell, even modern SQL databases are fine.
assembly
apl (k4)
forth (bootloader)
snobol (spitbol)
C (small subset)
sh (Almquist-like)
sed (not GNU)
nawk (do not use added functions such as strftime)
execlinebHere's a couple of machines that others have built:
Also, m4. I use it together with awk and bmake for a couple websites. I plan to port awk scripts to sth. else though, I keep forgetting awk.
I expect it to stay around a good, decent while :)
Edit: also a long-term Emacs convert, just haven't written any of the elisp myself.
Using tools lik Org mode, Rmail, Elfeed etc. gives you many opportunities to write some useful elisp, which is a pedagogical experience.
Emacs is like the mildly beautiful geeky girl which you fall in love with: whenever she spots you inclined to some new cute girl, instead of going mad with you, reveals such a wonderful piece of her interior world that you just forget the other one :)
Ada for fun, though I'd say Ada 2012 is a bit like C++11 in terms of “basically a new language”. People do seem to have a perception of Ada as ‘old’, though I'm not sure why (it is, by my account, more ‘modern’ than, say, Go – actually, it's not unlike Go with a nice generics system).
This is not actually a joke comment -- it teaches assembly language programming. Not 6502 specifically, but the fake architecture looks a lot like 6502. You work up through a set of more and more challenging assignments until you have to write a sort. I really enjoyed it and would consider it a great introduction to basically any assembly language.
I'm working on the latest revision of a client's CF intranet app that been in use for fifteen years, now.
ECMAscript style coding support that unlocked the underlying JVM in its entirety is one of those things.
It was one of the first, and only languages and platforms that was made for the web first, instead of extending non-web language to the web with a framework.
I am working on a new project in Django that is going to be interesting, so we'll see how that pans out.
Ruby, age 21. Web development, some text processing scripts. Design started on February 24, 1993 first release on December 21, 1995. [1]
Python, age 25, almost 26. Web development. Implementation started in December 1989. First release on February 1991. [2]
JavaScript, age 21. Web development. Designed and released in May 1995. [3] However if Ruby and Python are clearly the same languages they were 20+ years ago plus the natural evolutions, I don't know if the JavaScript we're using today has anything more that a resemblance with what it was back in 1995. After all we say we're using bash (Bourne Again SHell, it couldn't be more explicit) and not sh, speaking of which:
Bash, age 27. Scripting. Coding started on January 10, 1988 and released on June 8, 1989 [4] If we count the Bourne shell, that is from 1977 (age 39), coding started in 1976 [5]
Erlang, age 28. First prototypes running in 1988, work on BEAM started in 1992, in production as we know it in 1998 [6] Actually I'll be using Elixir for backend coding. Sometimes all what an Elixir module does is calling Erlang modules so it's handy to code that directly in Erlang. The Elixir compiler handles compiling and linking Erlang well.
[1] https://en.wikipedia.org/wiki/Ruby_(programming_language)#Hi...
[2] https://en.wikipedia.org/wiki/History_of_Python
[3] https://www.w3.org/community/webed/wiki/A_Short_History_of_J...
[4] https://en.wikipedia.org/wiki/Bash_(Unix_shell)#History
[5] https://en.wikipedia.org/wiki/Bourne_shell
[6] https://en.wikipedia.org/wiki/Erlang_(programming_language)#...
Considering that PHP, Java, C++, Perl are also in their 20s (and Objective-C is 30+), should we really call them old languages or old should that be reserved to something dating back to the 70s or the 60s? (C, COBOL, Fortran).
Here's a mention of the software in question from the UK's Unix User Group newsletter in 1995: https://www.ukuug.org/newsletter/linux-newsletter/linux@uk13...
It's possible I will start to write C++ also.
I suspect I may have the only B compiler in the world for the VideoCore IV processor.
I would like to replace it very much, because I don't like Perl 5's type system very much (and something like Moose is overkill, IMHO, for a 500-line-script).
But it's just so damn useful, and most of the time I can get something to work faster than with Python or Go. So I might not love Perl, but you could say I respect it very much.
I would be interested in this: is it open source?
I develop mainframe software.
I think the Redbook titled z/OS Basics has some JCL examples and exercises in it.
I also found this through a quick search: http://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm...
EDIT: Removed the "naive" part.
When embedded into a C host applications, it is really nice, though. There is also a port of Lua 5.2 to Go, which has a slighty confusing API (to me, at least), but the documentation makes up for that.
But the standard library is very small (deliberately), and while LuaRocks is fun, Perl, Ruby, and Python have a lot more libraries available. Plus, concurrency in Lua is ... nontrivial I loved concurrentlua, an attempt to implement Erlang-style message passing in Lua, with coroutines instead of processes. But it was kind of a pain to get it to work, and I think it was unmaintained.
When using Lua as a standalone language, this situation bothers me enough to stick with Perl or Python. However, when using it as an embedded scripting language, it is not a problem at all, because you will probably supply whatever library/API you want to be scriptable yourself. At that point you only care about the language itself and the API of its runtime, which is - IMHO! - where Lua really shines.
I make web apps and started using Perl for cgi scripts back in `97 and still use it. Most of my app code now runs on the client side with Javascript so I don't do much with perl anymore but I still use it for most everything on the backend.
Learning to code something with new or different languages is not something I do without good cause and/or necessity. I haven't ran into that much building web apps.
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.
Pharo/Dolphin Smalltalk, FreePascal, Racket/Chez/Guile/Gambit(via LambdaNative) Scheme, Ada, Erlang, Forth(8th) for speculative/personal projects.
Edit: Bits of LaTeX and groff here and there.
Thankfully we have written gobs of Python to do most of the data management, multiphysics coupling, multiobjective optimization, etc. so it's really not too bad.
I just wish the K language or KDB+ was open sourced. We'd see people from just about every industry drooling over how nice it is.
I had a contract doing C++/qt stuff 2015/2016. So I could conjure up my own reasons for and against. But I am curious about yours as I am largely ignorant of pascal.
I had to develop a simple GUI application for extracting a few hundred GBs of image data from a complicated folder structure created by an automated microscope. It had to run great on windows and mac os (and linux of course won't hurt, just in case, as it has some desktop use in academia).
I developed the tool in linux (xubuntu), and:
- Compiled it without change on windows (Just press that green button).
- Compiled it with one single change on Mac OS X (some cthreads library import missing).
I finished the project from design to final approved product, INCLUDING learning the language as we went, in 80 hours.
I find this pretty amazing.
(The tool: https://github.com/NBISweden/mdc-file-export )
Also, I guess writing code in Python 2 is considered outdated nowadays, so that too. Plus the usual shell scripting (bash on Linux and simple batch files on Windows).
I do hope to avoid writing any new Fortran this year, so there's that. Some of the less performance critical code will instead involve Julia, and I've been experimenting with D and Rust for fun. Not sure which category Java and C# fit in, but in all probability I'll also use those at some point.
And finally, LaTeX. Very old and, unfortunately, indispensable.
Edit: Well not all of it. I'm also learning rust and scheme in my free time.
I feel your pain. :-D
Also, there is Lazarus which seems to be the FreePascal-alternative to Delphi. I took a look at it when inheriting a Delphi application at work, but it crashed on me a lot. Still, it's there.
- Python (mentioning since it is over 20/25 years old, though used a lot currently by many, of course).
- C (evergreen, for some uses, IMO)
- sh / bash, with sed/awk and friends (the common Unix command-line power tools (filters and others))
(Talking about both of the two points above mainly on Unix / Linux, though both are quite useful on Windows too - sh / bash and friends via cygwin, UWin, Ch and similar tools, and now / after some time with the Windows Subsystem For Linux.)
- D (if it can be called an old one)
- Probably Pascal (via FreePascal), for small tools, for fun and personal dev use (e.g. utilities), on the side, to start with, maybe see if I can make something bigger and generally useful later (I have a somewhat long prior background in it - and in C). The compile times are fast, like D and Go, and executables are small, which are two of the reasons. Haven't checked runtime performance of it much yet, but likely will not be shabby, to say the least. And last but not least (reason), because it is like C with some niceties added, which makes the code more human-readable and maintable (though I have no trouble understanding well-written C, my own or others'.) Also, modern Pascals like Delphi's Object Pascal and Free Pascal are a far cry (much better) than the academic Pascal versions that were taught in universities years ago.
Edited to add (after seeing others mention it):
- SQL (had forgotten it because it is a bread-and-butter thing used in most of my projects, irrespective of other language used)
SQL, bash,awk & sed
"PHP", It's not old, but it's not hip and plenty of people believe it deserves to die and has nothing to offer :-)
It can be surprisingly fun to see if I can get something done in "pure" SQL without any procedural code.
I feel a little sorry for the poor soul who may one day inherit that code, but on the other hand, at least I write comments to explain why I do things in a certain way, which is more than my predecessor did.
- sh/awk/sed (I don't really think of these as separate languages): mainly for scripting things that aren't worth firing up python for or that are easier to script this way
- javascript: for web front ends
- html/css: ditto
- possibly c: for particular things where I need more speed/control over memory than python can provide
For fun, though, there's QB64's implementation of QuickBasic. I also have my old 8088 up and running again, and GW-Basic and ASM there. I started with GW-Basic when I was about 4 years old on that old 8088. Two 5.25" drives, no HD, 640k RAM and a "Turbo" button. What's not to like?
Co-worker introduced me to Lazarus / FreePascal a few weeks ago, and I decided to dust off my old pascal book from jr. high school and see what I can remember.
If I can find a use for it, I'd like to dust off and freshen up my Fortran77 memory. I know there have been updates, but Fortran77 has a little special place in my memory since that was the first language I got paid to know.
Then there's COBOL. No idea why, but I want to revisit it and see if it is as bad as I remember.
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.
There are several hundred thousand lines of the language in the main application where I work.
While there are definitely some major issues and pain points with it, it's actually suprisingly powerful and the language itself is still being developed.
We've got a lot of things you wouldn't think would be in a BASIC, like classes and object-oriented programming, a "UI" library that targets the web without any (tm) changes (in practice it misses that mark, but it's still extremely useful), support for the big 3 platforms, and more.
I don't deal too much with it though as most of my job is connecting new web stacks up with the pxplus backends.
Though I don't consider Fortran "old" as it has many shiny features.
Bash - I already know some Bash, but I want to become a bash guru.
purpose: sysadmin, automation, server-side programming, daemon, shell / interactive shell, command-line tools etc.
well ... it's not that old (cerca 2006) but it is considered dead LOL
Delphi - crossplatform development, tools
SQL - see above
C++/C# - tools
bash - scripting, mostly for managing servers
Our COBOL comes from a software vendor, so rewriting it means waiting for them to decide that the cost of redeveloping decades of complex business logic in a new language/toolset outweighs the cost of supporting and enhancing these COBOL programs.
Fortunately it's a mostly read-only codebase. The number of times we've changed the COBOL code ourselves can probably be counted on one hand.
powershell (11 years) - basically just a better version of bash with 'select' and 'where' replacing scraping for text with grep/sed/awk
javascript (21 years) - finally ES5 and 6 have added some stupidly obvious things like multiline strings, array.includes(), destructuring, etc - it's actually a pretty good language now.
For my spare time work mostly Fortran, C and C++ qualify as old languages I'll be using. These I use to dabble in research (physics) more for fun than anything else.
[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)
And of course the usual Linux scripters: bash, awk, sed, etc.
And here's the package manager:
And here's the init system:
VBScript
JScript
- Perl
- HTML (old?)Usually I get about 20% in and then give up on it. I'm going to really force myself to get through the other 80% this year.
- Some MS-DOS Batch language
- Clarion
* Just installed a copy of the original Turbo Pascal on FreeDOS and looking forward to re-remembering my first 'real' apps I wrote in it...
We still use C++ and Fortran at our company.
The oldest thing I periodically touch is VBA for Excel
- Python (esp. Django, which is for some reason uncool)
I also have this weird desire to jump back into C, just to refresh myself.
I just enjoy cracking old Apple ][ games in my spare time, it's an incredibly rewarding challenge.
We have a bunch of mission critical desktop application that run on Powerbuilder.
ATLAS[2]: an utterly repulsive, "self-documenting" language designed specifically for test applications, which has somehow managed to outlive the demise of its guiding IEEE standards committee to the dismay of many a aspiring young engineer. Paradigms include 20+ token statements as a sensible method to toggle a switch best described as abusive by certain alumni of aforementioned committee; proliferation of subsets which aren't even notionally interoperable because it makes people feel special; and nerfing canonical features related to trivial GPIO control only to adopt a proprietary language such as...
L200[3]: because languages are always fun when comma delimiters are strictly optional most of the time, and it's easier to metaprogram an application than to actually write it. Build/runtime/debug environment is also fun when it's technically an obsolete filesystem emulator executed by an obsolete OS running on an obsolete hardware architecture whose performance[4] pales in comparison to a 1st generation RPi.
[1] https://en.wikipedia.org/wiki/DIGITAL_Command_Language
[2] https://en.wikipedia.org/wiki/Abbreviated_Test_Language_for_...
Everybody is es7 and es latest. I feel old.
C, ksh
For one of the retailer's POS.
it's crazy how far those will get you...
Can't seem to ever lose it. Financial Institutions -- think Hedge Funds, Banks, Brokerages) -- are still drowning in bloated complex Microsoft Excel spreadsheets with 1000s of lines of hard-to-maintain-and-source-control VBA code.