I had a notion that Pascal was a "toy teaching language" too, but for what I was doing that didn't really matter.
I had a notion that Pascal was a "toy teaching language" too, but for what I was doing that didn't really matter.
The main advantage of Pascal is super fast compilation, but C++ modules should close that gap once they make it into the standard.
This really means it doesn’t permit variably-sized arrays without a hassle on pure language level, so you can’t fall from a bike because it’s wheels are buried in the basement. Manually-specialized Containers like TStringList still use GetMem() and align a pointer to an “infinite” array to that block, shy trick pretending to be safe until reinvented by mere mortal. Iirc, you had to destroy ^properties in destructor by hand too.
Pascal only seemed easier because of three things: a) explicit pointers are hard, b) strings have explicit length of 8 or 16 or 32 bit, and that was also a mess, especially in C interfacing, where PChar worked as intended only half of the time, c) no CS-hard tasks were solved in Pascal by RAD-programmers.
Don’t let your fond memories trick you too much. You can get the same/better behavior and speed by using glib, apr, objc, etc and not using pure C arrays at all.
Quite a few parallel programming research papers were done in Concurrent Pascal during the 70s.
Besides UCSD Pascal, there were a few other OS CS research done in Pascal variants.
Variable legth arrays were available.
C string manipulation is a joke as well, given that in 2017 still doesn't have a way to handle unicode in spite of wchar_t.
The whole point of unsafe code being hard to reach for, is to force people to think instead of producing yet another artifact to hang on the CVE list.
Finally, if we are no longer discussing pure C then Pascal also has libraries and extensions, nothing special about C here.
In any case, there is no need for C when we have C++, other than keeping UNIX kernel devs happy, and legacy code.
I almost laughed at a friend who decided to implement C in a compiler course. Having a preference for programming in a language is one thing. Trying to implement it is quite another. He should have realized that. We both had two page grammar that defined Pascal from our high school days.
I still skim Slashdot too.
Most of the time I'm working on ancient versions of RHEL that are never connected to the internet so I don't exactly get to use "stacks" or anything that wants to pull code from Github. If it doesn't come on the RHEL 5.5 disk it's not available. You might be surprised how much you can do with a modest CGI script, a touch of JS, and some basic styling CSS.
What is Slashdot's strength from your POV?
But surely you've heard of Red Hat itself? In the early 2000s, Red Hat Linux broke into a couple directions: "Fedora Linux" as the community version of the OS, and "Red Hat Enterprise Linux" as the supported, enterprise-level version of the OS (and CentOS as the community-supported version of RHEL).
Slashdot picks up stories that Ars and HN miss sometimes. It just adds some breadth to my tech news sources.
The place had literally piles of OReilly books and that was it. Those were gold.
When I got home I ran NetBSD on salvaged sun4c and sun4m kit.
I was taught Pascal first, then C++. Pascal really helped with learning the basics. I think jumping right into C++ or Java would have been confusing.
As far as stacks go, I use whatever suits the application I want to write. I use: - PL/SQL (mandated by my employer) for generating large batch files in an ETL process - Python for validating the files mentioned above - I'm evaluating the OCaml compiler set for a language I'd like to create - I'm interested in Elixir for back end processes - R for ML - Prolog for prototyping a rules engine that may become the seed for a product - I'd like to get familiar with a JS-based web framework like Angular 2 or React or one of the other ones I've been reading about - I'm looking at Flash to develop a game with my daughter, who seems interested in coding.
I think it's important for older developers to assure younger ones that you remain interested in trying new tools and technologies as you get older. The curiosity and passion for creating don't abate. But, after you stay with an employer for a while and develop critical applications for it, then you get caught in maintaining it in that technology. Essentially, you get frozen in time in a technology stack due to the success of the app you wrote.
You also begin spending more time on ops and support.
But, you pick and choose times to introduce newer technologies, which you largely have to evaluate on your own time.
You don't have to leave the field or slink into irrelevance just because you're older.
Currently working in python in fintech environment.
JavaScript when doing web development, TrasactSQL, PL/SQL and pgSQL for database manipulation.
Plus lots of other languages and tech, keeping an eye on what might be interesting to focus or advocate to customers.
Admittedly I didn't start with Pascal, but rather with BASIC and several assembly languages (1802, Z80, & 6809 were among the first I used). I learned Pascal after C, actually. I like things about both, but often wish that Wirthian languages would have won out.
FWIW, these days I primarily use Java, C, C++ (when I must), and a smattering of other languages, with libraries and such chosen to match the problem at hand and the environment in which it must be solved.
My stack now is... diverse. Python, Spark, Java, React, Node, PyTorch, Scikit and occasionally R.