Whenever you wanted to know syntax of some command, you print this command, press ctrl-f1 and is presented with docs, complete with a working example. It was insanely great. Remember, stack overflow didn't exist then.
Infinite loop: see Loop, infinite.
Loop, infinite: see Infinite loop.
Correction: Rust's help and documentation is HTML-based, and getting a local, automatically updated copy is trivial.
> even "local" docs launch in a web browser
Uh, so what? Can you name a better format for programming language documentation that's also ubiquitously supported?
Maybe you mean Rust's documentation is rendered to HTML. In which case, sure, but so what? Good docs can be rendered to non-HTML formats too, typically for IDEs to display quickly without needing to load a full browser.
It's one of the features I miss most as I code Rust, and the lack is very detrimental to the coding experience, as pulling up a browser is a massive context switch.
Info format. It's supported by Emacs, and Emacs is the most ubiquitous of IDE's.
Sorry, have you been in a coma for 30 years?
I said "ubiquitously supported". There are several orders of magnitude difference between info format support and HTML support.
> Emacs is the most ubiquitous of IDE's
That's laughably wrong.
albeit there's still zcat
"Never trust a compiler that doesn't fit on a single floppy"
I'm coining that second expression right here on Hacker News, today, 1/22/2020!
I'm fairly certain no one has said it prior...
But if they have, then my humble apologies, and in such case I'm un-coining it... <g>
In a time before the internet, it used to be that books, and occasionally magazines, were the initial entry points to understanding software, hardware and electronics. Then the BBS came along, these secret islands of knowledge and trade.
I learned Pascal and assembly on Turbo Pascal with trial-and-error and lots of context-sensitive help. These days, development is mostly fragmented and half-working. Progress is neither linear, increasing nor assured, and much is lost, reinvented not necessarily as well and lost again.
Also, eventually coding will decline or bifurcate more because general AI will allow non-programmers to ask a machine to do Star Trek-like self-programming. Essentially all office jobs are vulnerable to elimination as mechanical machine operators.
> Progress is neither linear, increasing nor assured, and much is lost, reinvented not necessarily as well and lost again.
The big difference is that we are now networked. The target MSDOS environment was not a moving target and had no security considerations. The world is very different now; we do so much programming in the browser because it's the one single cross-platform zero-friction environment we have. But those reasons also make it a battleground between platform monopolists.
There is also so much more software. Part of the problem that Stackoverflow solves is dealing with this. You can't be an expert on everything, there isn't enough time and it moves too fast. So you need a quick solution to incidental problems so you can get back to the "core" problem.
(credentials: the code I wrote at age sixteen for doing 3D rendering https://github.com/pjc50/ancient-3d-for-turboc )
Affordable C compilers (for a teenager at least) were not really a thing at the time (IIRC, even the DOS stuff, if you owned such a machine which I did not, still cost a couple hundred dollars around 1989-90-ish). I didn't manage to get a C compiler until the mid-90s when I picked up a copy of Turbo C for DOS, but I still think I paid $100 for the privilege.
> zero-friction environment
Giggle.
Maybe I'm just old, but I'm probably going to retire, and AI is not going to replace any programmers.
From what I see, the quality of the software in Corporate America reassures me that programmers will have jobs for many decades to come.
We aren’t nearly as close as you suggest do the level of code generation that would replace the bottom quarter of the labor pool even, but if that day ever comes I believe it will be really profitable for the top 20-30%.
'Eventually' is likely to be a very, very long time. I doubt we'll have self-programming systems like that even in my children's lifetime. It will likely take AGI to do it. There's the classic tale of programmers back in the 90s quiting their jobs because they thought Visual Basic would let non-technical bureaucrats write their own software, so there would be no need for specialist software engineers anymore.
One of the world's top self driving car engineers reckons we might never get Level 5.
I'm not an AI denier. Eventually we will get AGI, I think it's inevitable. It's just that the time horizon is so far off it's not really worth worrying about. We don't even have a clue how to go about designing it's general operational parameters or architecture yet.
I have some minor-level experience with self-driving car software, algorithms, etc. The majority of this is from various MOOCs I have participated in over the years, as well as research papers, books, and other things I have read and consumed. In short, I am not an expert, but I am not unfamiliar with the technology, either.
I personally think we'll never see actual widespread usage of self-driving vehicles outside of a very few narrow and carefully controlled (and regulated) cases. At least, I suspect, within my lifetime (which honestly, I'll be lucky for another 30 years or so).
My reasoning is that people will only trust perfection when it comes to riding in a self-driving vehicle. They will only be willing to use one if they can be assured that it will Never Crash, or be crashed into. They have no problem driving a car themselves, or being surrounded by other people driving cars. They have no problem with those crashing and even killing people - maybe even themselves (though they tell themselves fairy tales of it-will-never-happen-to-me to soothe over the reality). But introduce a machine into the equation...
...and that machine has to be Perfect. It cannot make any mistakes. It must avoid issues and be Safe 100% of the time, no exceptions.
In other words, people want the impossible from a machine, but will give utmost allowances to themselves and others as "humans".
I think a lot of this has to do with assignment of blame. When they crash or are crashed into - there is someone to assign blame to; themselves, the other driver, etc. Someone they can yell at, figuratively or literally.
A self-driving car? No one to yell at. No one to assign blame. Nothing that will feel bad for its error or failure to avoid something.
People can't handle that. They don't want a self-driving vehicle that has a safety factor of say, "seven 9s" - it has to be 100% safe or nothing. Because even if it makes a mistake only once out of a million miles of driving, that is still not safe enough. They want the unobtainable - a perfect machine, a machine that will never fail. Nothing like that can or will ever exist (basic laws of thermodynamics prevent it, for one thing).
Even though they themselves, or even the most professional of professional drivers - can't even come close to approaching this level. It both madness, and understandable at the same time.
From what I've seen I think your model of human behavior is flawed. Aircraft have been mostly fly-by-wire for decades and software flaws have led to some crashes (most recently those of the 737 Max), but that hasn't stopped people from flying in planes.
People have already been killed by self-driving cars, but that hasn't stopped the testing programs. Tesla automation (though far from full self-driving) has led to a number of fatal accidents yet people still buy Tesla's and I haven't heard of any public outcry to ban them from the roads.
I too am skeptical that we'll be seeing full self-driving cars anytime soon, but not for the reason you give.
I think the real issue is that AI-like technology has a 90-10 problem. It's relatively easy to get to 90% of human level performance but that last 10% is much much harder - unpredictably harder. Unfortunately self-driving cars are an area where 90% isn't good enough, even 99% isn't good enough. You probably need to get to something like 5 or 6 9's to be acceptable for broad general use and no AI-like technology has yet gotten anywhere close to that.
EDIT: I didn't mean to imply that the 737 Max is fly-by-wire, but the MCAS system that caused the crashes is a comparable technology.
That leaves more time for the interesting problems. I think that makes programmers generally smarter than before. They start from a higher base and can climb more quickly.
Also, you’re overestimating the potential trajectory of current approaches to AI.
> coding will decline or bifurcate more because general AI will allow non-programmers to ask a machine
I was expecting this development with the rise of React since at least the visualization part has become completely declarative. It's no rocket science to automatically transform that, in fact being an XML dialect there are a lot of tools available for this. But still, even in 2020 people still make money with writing HTML/CSS either plain or within a CMS.
In fact even a reverse development happened in some regard. In the 90s it was quite common for people to write CRUD apps running in Access, FoxPro etc. These tools - like Delphi which might be closest to that - practically disappeared.
The analytical load is still there and cannot be abstracted away. The decline of Access etc. happened because many aspects couldn't be mapped. Not to speak of all the nitty gritty details needed to make applications run safely and maintainable. There's still a very long road ahead to automatize all that, especially in a way that it consumes only a reasonable amount of CPU, memory and storage...
I don't think SO has dumbed down people. It's just the average level has tanked because of influx of people in tech. In 1980s average computer person was highly skilled, educated and intelligent, because even to get access to even the simplest computer required a solid dedication and investment. Now, tech is ubiquitous, easily accessible, and lots of people with most different backgrounds jump in. You'd be amazed how many 'developers' fail to solve FizzBuzz test. We actually DO test applicants with it, and results are extremely appalling. I am unable to understand how a person who calls himself a developer and has experience can fail this, but I have learned to accept this as an observed phenomenon.
My frustrations as HN comments:
* Selective bias in candidate selection - https://news.ycombinator.com/item?id=22098101
* Low productivity environments - https://news.ycombinator.com/item?id=21965539
* False equivalence - https://news.ycombinator.com/item?id=21904199
* There are only 2 APIs for working in the browser and yet most developers can't figure it out to save their careers - https://news.ycombinator.com/item?id=21849398
* Invented Here stupidity - https://news.ycombinator.com/item?id=21417450
* The DOM is a 20 year old standard that is the primary interface to any markup language and the primary interface when working in the browser, yet it is still somehow an arcane mystery of lost knowledge - https://news.ycombinator.com/item?id=21069571
* More about hiring bias - https://news.ycombinator.com/item?id=21015495
* Excessive sensitivity not found in other industries. I have heard that several psychologists are predicting my children's generation will be the most offensive generation as a counter to the extreme sensitivity (fragility) - https://news.ycombinator.com/item?id=20668380
* More selective bias, online code tests. Now when I see online code tests without extremely specific grading criteria I instantly terminate the conversation. - https://news.ycombinator.com/item?id=20605329
Sure... when general AI becomes available, flexible, and has solid usability for something like this. Which will be about the time that faster than light stardrives become common and our meals are materialized out of thin air on demand.
Despite perceptions, the last few years' "AI boom" is mostly marketing. Advances in processor power have made deep learning algorithms practical outside lab settings, but we're not even close to a "generic AI" that can think as well as even a dog can. That's decades away at the earliest.
Right now, we don't even understand how our own brains work.
StackOverflow has many great explanations, which are no different than reading a chapter in a book (it's just a book that is extremely relevant to you problem).
The problem is that lazy people demand code dumps, and lazy people provide code dumps instead of explanations. This then becomes a feedback loop as people get used to this degree of laziness.
This is especially rampant for Web topics, and to some extend also a counter-argument to the Borland help pages with examples: When presented with a fully written solution, people will blindly copy it and only do the minimum amount of work to make it run.
Perfectionism is not required, and can get in the way of professionalism. This is about a minimum amount of responsibility.
(Learning is different though.)
Miles ahead.
Pascal is what we need, but C is what we deserve. Billons of dollars wasted in it.
What it have bad is the massive mismanagement of the owners, and that translate to lack the influx of talent to it.
Note: I'm moderator in a Delphi forum and use it for years. I'm now in rust, and is great yet:
- Some of the problems that rust fix? Delphi too decades ago.
- Delphi still compile so fast. All the stupid c-based langs are turtles. Including LLVM. Is a sad joke that "I use C-/C++/rust" for performance and the compilers NOT PERFORM. Period.
- All the other currents langs on earth, all of them, still fail at build a GUI easily.
- Only recently, with Go and now rust, people rediscover the joy of easy deployment. Delphi have it decades ago.
Of curse Delphi is not perfect, and we the users know it. Sadly, in this industry worse is better and without a path to improve the lang you are at mercy of the owners. But like smalltalk, foxpro, hypercard and others, Delphi is a testament of what could be a decent lang/environment.
That the community at large still inflect itself with massive amounts of pain and billons of wasted effort with c/c++/js and still refuse to learn? Is something I will never understand.
P.D.2: If this sound like a rant? Yes. My super-duper machine is still compiling with rust and I'm frustrated, because this post remind me that this pain could be avoided...
The reason I stopped using it was that I discovered that there are many more program types than Windows GUIs - and there, C++ (or sometimes C) is really the best. High performance lock-free lists? Support for obscure network protocols? Containers with custom allocators? Delphi does not really work there.
Is interesting to note that you can see "High performance lock-free lists" in many langs, but near none have good GUIs builders. Good GUIs builders are harder, and your "High performance lock-free lists" is easy, also you can use C/C++ libraries in Delphi too...
> I know Delphi!
I would argue you can made good courses in any language and it would seem more convenient to teach in something that has better transferrability into industry.
Also the response is likely aggravated by this quote from the source article:
> a curriculum that has taken heavy damage from the adoption of Java and C# in the early 2K’s.
wut?
As an example, the free version of Turbo C++ 1.01 that is available through the Borland/Embarcadero museum (or was at some point, i don't know if still is) has ~34 introduction examples (referenced via their guide) that outside of a couple, use only basic stdio and stdlib stuff (these 2-3 examples that use a non-standard header use conio.h which AFAIK is borland specific, though Watcom/OpenWatcom and Visual C++ also seem to provide the used functions) without any DOS-specific functionality (be it far pointers or whatever) and could compile with any modern compiler.
Now, a minority of us believe that desktop apps are really worth fighting for. They are fast, they give user control over their data, they can work offline, and the subscription model is optional rather than built in. Some in the mainstream would like this to be killed. Some companies like Apple approve it as long as they get their cut. But most simply don't care. If you don't want a future where everything you use is controlled by someone else, then the Turkish decision is not meaningless.
If you teach C, at least teach C99 using a contemporary compiler—C11 was available when this all occurred. At no point did I suggest that a different language or paradigm should have been taught.
If the goal is to get more students to become programming literate, then the last thing that I would want is to pick a random flavor of the day language, with some frameworks, and some "best practices" debated to the oblivion on HN or Reddit. I would want all schools have a pretty standard system, with identical software that works identically because the goal of that software is to act as a pen and paper in a class. It needs to get out of the way.
Imagine the conversation had they picked C++ and do Linux. First, there's going to be a multi-year debate if we should be using Ubunto, Centos, Arch, until some pointy headed expert says "The future is in CoreOS!" just before everyone decides to standardize on Fedora. After that there would be a fight about versions, because everyone knows we should always run the latest. That's except for the group of people over there, that are refusing to run the latest and want to run the proven. Oh and they do not want to do C++, they hate C++ and say it should be Rust and since it is a Linux system and shadow IT is pretty easy on it, they are going to teach Rust! Or mostly argue about teaching Rust... etc... etc.. etc.
Here's a thing - if 10% of students gets out of the Delphi environment and starts messing with GCC for any reason then the program already succeeded in achieving the goal.
A little bit too harsh. As the article points out Delphi is currently #12 on the TIOBE Index [0]. Above Go for example.
And Delphi itself was a standout leader in technology, a huge inspiration for C#, and still a key technology used by many people today. It's just not well known. Not well known != ancient.
5 or 6 years ago, our ex-minister, claimed that it is dangerous to work with computers since they can be challenging for the mind in a conference about cloud computing. Let that sink in.
I wouldn't call Delphi ancient. It's not like they haven't been updating it. Delphi can target Windows, macOS, Android, iOS, and Linux. It's pretty good:
Delphi is a modern development environment. I haven't used it recently, but it was incredible in the 90s/00s and I know it kept adding features and platforms. AFAIK Beyond Compare is built with Delphi.
Delphi isn't ancient, if anything chances are some of the tools people use nowadays on Linux are older than Delphi.
I remember back then(2002'ish), Pretty much all CS labs had Borland Turbo C.
The funny thing was the output prompt would disappear after printing things, so to hold it there, people would add getch(). This was so common, I remember at one point people treated getch() was something you always added at the end of the main(), like a return statement.
If anything it should be mandatory to learn something else. It might be the only non-work programming language they will ever learn. Cradle to grave Python / Java?
Would Common Lisp / Haskell be considered a bad / good / ancient choice?
Python is great for this. You can have kids building whatever in class and they can go home and use the same tools and make videogames or visual novels or whatever else strikes their fancy, and when they get hired still use the same tools.
My main issue with haskell is that it's likely not very transferable. That isn't to say you shouldn't be able to use it or teach it - maybe you can teach something unique with it you can't teach with other languages, but that needs a bit of explanation beyond just "well I prefer it".
The education should serve the students, not tickle the fancy of the teacher.
I thought this for a long time, having taught myself Haskell in university. I never regretted it, but I'll admit I never thought of it as a practical choice either.
Then I ran into Rust, and found I was somewhat mistaken. ;-)
If they just learned anything they'd progress at roughly the same rate, but when their motivation is impacted it makes a bigger difference.
Common Lisp lacks a static type checker, or any decent type system. These days I consider that a catastrophically bad design choice, and I can't justify teaching it as anyone's first language. It's also, well, it's design by committee.
Scheme might be better -- at least then you'd be learning about call/cc. If you aren't learning a language purely for work, then I think learning it should teach you something new. Scheme, Rust, Haskell, even Java/Kotlin if you've never used a decent IDE -- all of those can teach you something. CL sort of can't, anymore, though for a long time it could.
Does anyone have a recommendation for a good, up to date, open source, introduction to programming? Ideally something that uses an experienced programmer (i.e. me) to guide.
The first half of the course is mostly in C and then switches to Python, and I really think it is a very well designed course that get students doing some interesting stuff very quickly while building a solid foundation for future learning. There is an online version of the course and students can watch all of the videos and lectures. I believe there is also a teacher training program for the curriculum.
I was surprised when my son came home and started asking me questions about malloc and free, but he has learned a lot in a very short period of time.
At this point I think it's probably a matter of "you either have it, or you don't". All of the people who succeeded "already knew" how to program, before I even showed them, or they never managed to learn.
And my experience is even with people who actually did manage to secure a programming job. In my opinion they still don't know the basics - they blindly follow "procedures" and mostly do copy/paste programming, without being able to grok the idea and why these things work the way they do..
Likewise, getting into intimate discussions on file encoding or strings in memory just isn't going to be retained by someone whose major interaction with a computer is facebook.
Focus on practical tasks, but take time to explain what code is doing in plain english. If you've done rubber duck debugging, you're aiming for that level of simplicity in your explanation. Avoid technical words, use simple metaphors and generally avoid the history lessons. Once you establish a baseline of skill in the developing programmer, swap the roles - have them explain their code to you.
"yeah, that's a lot of copy and pasting isn't it? Want a neat trick to save yourself some effort?"
painful 16-bit near/far memory model
a single task operating system (DOS) that has been long obsolete
no support for networking or threads
I could go on and on.
Would you advocate pilots stop learning to fly in single engine prop planes and instead jump right into the cockpit of an Airbus because that's what they will encounter in the workforce?
Any why are doctors practicing on dead people when clearly they can't possibly help them or cure anything that way...
I don't think your example is a valid comparison. It's more like do you think all teenagers need to learn to drive a horse driven carriage before they learn on a modern car?
That makes it an odd choice, considering gcc and clang are free and cross-platform.
Hell, they even have a C89 mode if you'll be deep in the cold, cold ground before you recognise // style single-line comments.
It's not C that's obsolete, it's MS-DOS and the 16-bit segmented memory model it uses.
"Fond memories" is easy to explain if that's what you grew up with. As for simpler, let me play devil's advocate for a bit: our "modern flat model" looks simple until you find out it's not really "flat". The 8086 model is basically "(segment << 4) + offset", while the "modern flat model" is actually a multi-level table lookup.
Some 32-bit parts are totally flat. Like low-end ARM parts with SRAM and no MMU. Compare that to a 8-bit or 16-bit PIC microcontroller where you need to bank switch to have a usable amount of memory for your application and its heaven.
But yeah, I see what you are saying. Still, pulling the wool over someone's eyes doesn't seem so bad to me about virtual->physical memory and TLBs as it does making them jump through a distinction between pointer types, but maybe I am in the minority on that.
Meth addicts don’t make _everything_ about meth.
I then found out that they were being taught to use Borland Turbo C.
I suspect the case for this is similar: Some person who once upon a time learnt to program and then never practiced nor developed their skills somehow got a job teaching programming, and is now trying to apply the ancient tools they were taught somewhere around the time when some fish decided to walk on land because its all they know.