Hacker News Reader

At least from the systems programming perspective I think productivity gains have been significant. Valgrind had _just_ appeared as I was doing my undergrad and it allowed me to focus on the high-level math of data structures -- as an example -- compared to my non-Valgrind using classmates that were struggling with memory bugs (which, of course, I did too, but to a less degree). C++ has noticeably improved since then, if you can hew to the newer bits of the language and keep all the arcane bits in your mind. Rust has arrived on the scene, inspired by Cyclone, C++, SML and is a serious jump in productivity over C++ because the compiler keeps track of all those arcane bits. If you squint, Go's in the mix for web stuff that doesn't mind GC. It's a shame ATS didn't become more of a thing, Ada has made real strides back from the dead, especially if you can stick to SPARK Ada. We're even seeing more formal verification of complex bits of software in systems-land, something that seemed basically impossible when I first read about Coq twenty something years ago.

I do admit, though, that front-end seems like a wild west presently, to my ignorant eyes.

> Ada has made real strides back from the dead, especially if you can stick to SPARK Ada. We're even seeing more formal verification of complex bits of software in systems-land, something that seemed basically impossible when I first read about Coq twenty something years ago.

I really agree with this. The situation is a bit crazy. Since formal proofs are hard, the alternative taken is giving no guarantees at all. That's bad. Static analyzers can get really far. Contracts, even just at runtime are really useful. I don't want a piece of code to run if the precondition is not met, and I don't want it to return or have side effects if the postcondition is not met. This would rule out a massive class of errors. Of course, bonus points if you can do it at compile time.

Ada SPARK, Infer [1] and Dafny [2] show that rigorous engineering is possible and practical. Actually, Facebook (Meta now) argues Infer let's them move faster.

I think the problem is political and economical. It's hard to monetize this first. I wish someone like Apple took the plunge and rebuilt a simpler version of their stack using formal verification. It's the kind of thing only a large corporation or a government can do because it might take half a decade to take off. Once it takes off its unstoppable. Who would not like to buy e.g. a phone where most bugs and security breaches are impossible by construction? Verification also has a nice side effect. Change for the sake of change and featuritis are pretty incompatible with it.

[1] https://fbinfer.com

[2] https://github.com/dafny-lang/dafny

There's a bunch of interesting work happening in the blockchain space around formal verification languages that can compile to smart contracts.

Makes sense - not only do you lose money if you get it wrong but it is very difficult to correct!

The great thing about Ada/SPARK is that it has a package manager now (Alire). This means there are existing SPARK packages you can use, and you can share what you make. SPARK is also an Ada subset, so you can use verified components inside your Ada programs.

"It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source. You'd double click a button and it takes you to the already created "onclick" event where you do the actual coding. In a way, this is still similar to how you can "program" Microsoft Access today."

Yes! I remember Delphi as my first language in school, too. And later in university I could not understand, why in all the other advanced languages like Java, C and C++ doing the same was so hard.

Then I discovered Flash and later Flex with Flex Builder. That was a even way more powerful experience. You could draw up anything - and make a button out of it with a click. Or a sophisticated, reusable component.

And then it died, because of Adobes unwillingness to open source the technology (and their focus on performance and flashy features and not security). All the bad flash applets that were flying around existed, not because it was so bad, but because it was so easy even for total beginners to make something working fast.

But today? I am back to hacking scripts.

Yeah it really feels like we’ve moved backwards in some dimensions since the era of Flash.

I agree with the general sentiment of your post.

Regarding Java and C#, I am stunned by how good are IDEs now. To be clear, when I say IDE, I am specifically talking about a tool that enhances the edit-compile-debug cycle. Compared to 20 years ago when I wrote C, C++, and Perl, the IDEs were mostly terrible, except Visual Studio for Windows. The majority of my development cycle was all terminal-based: vim to edit, make to build (C/C++ only), gdb/perl -d to debug. Hoi, awful. (And, I still enjoy those all three languages!) As mega-corp computing slowly migrated to Java & C#, my productivity has increased dramatically. I guess at least 2x, if not more. Yes, some of this comes from how forgiving a modern VM can be (NullPointerExceptions, debugging, etc.), but a lot can ascribed to the incredible ecosystem of IDEs.

Regarding JavaScript, in the context of a modern web browser, high school students (in almost any country in the world) can easily Google a little bit, read some blogs, and then start GUI programming. And this doesn't require expensive, licensed software, like Delphi 30 years ago.

>And this doesn't require expensive, licensed software, like Delphi 30 years ago.

Delphi wasn't expensive for most of it's life, until they got greedy, and lost the market.

Lazarus is the modern open source replacement, it's mostly compatible with Delphi, and $1400 cheaper. ;-)

I programmed in Delphi for years and have done some toy things with Lazarus, so I'm painfully aware of the quality and reliability difference.

It is quite bizarre how us programmers, who make hundreds of thousands of dollars per year, are unwilling to pay $1,400 that will make us more productive.

I make $0/year, so my choices are more restricted.

How about the Delphi community edition? https://www.embarcadero.com/products/delphi/starter

You can use it for free util your revenue reaches $5,000.

Yeah, I've had it installed, more than once in the past few years, but I just can't bring myself to use it.

> It is quite bizarre how us programmers, who make hundreds of thousands of dollars per year, are unwilling to pay $1,400 that will make us more productive.

Not all of us. Here in Latvia that amount would be around a half of one's salary, quite likely more than that.

The further you move in the direction of poorer countries, the less the argument of "developers are expensive, everything else is cheap" actually holds.

I don't doubt that in some places a single decent AWS EC2 instance would be a developer's salary.

Lots of devs are willing to spend on tools but end up in workplaces where they're not allowed to install them, tools don't offer compatible licensing for that scenario, or where the workplace won't purchase a license for them in tandem with their personal copy.

Look at all the copies of IntelliJ (and derivatives) that are sold. I think people are willing when the price point is right and it can get into the workplace. I personally wouldn't spend $1400 unless I could make my life better from it somehow, and that would mean it making me significantly better at earning money.

How about, it is quite bizarre how people who employ programmers, who make billions of dollars per years, are unwilling to pay $1,400 that will make us more productive.

My first professional job was doing Delphi.

To prepare for that I got a copy of a version of Delphi for free on a magazine CD. Was still more productive than many tools now.

The web, and much of programming really, feels so far behind the curve of what's possible as a programmer. Take a dive into shader design in something like unreal engine 5, it sounds exactly like what you're describing in Delphi, mind you, I say this as someone who has never programmed in that language. The ability to drag and drop functions, compose higher levels of abstractions, and really all of the fun programming stuff we do can be accomplished in these engines. I've found it very enlightening, and even somewhat frustrating, to go from drag/dropping some graph nodes that generate a playable world for fun, and then back into the world of javascript for work where I am slinging 100s of lines of text-based code just to get a form button to operate correctly.

In game engines, and especially in UE where things like Blueprints exist, the low level stuff is just conveniently hidden or abstracted away. But the long textual code that makes the button work, eventually exists somewhere in there. At least when you write it yourself, you know who to blame (and probably where to look) when it doesn't work.

"the low level stuff is just conveniently hidden or abstracted away. "

Yes. This this is exactly what I want.

When I write an engine or framework, I will deal with low level stuff. But for basic tasks, I don't want to. But I have to, even where it would not be necessary.

"But the long textual code that makes the button work, eventually exists somewhere in there."

Also there exists even longer textual or even binary code that makes the code for the button work, etc. etc., but I still do not want to deal with it on a daily base. When I make an button, it should be as simple as possible.

Where is it positioned. How is it styled. Where is the onclick method to handle it. Those 3 things I want to do with simple clicks in the IDE.

Everything else is only distracting.

> Yes. This this is exactly what I want.

But the more abstract you go, the less efficient does your editor become. And speed of development goes down. It's not a simple - just put more abstraction.

"It's not a simple - just put more abstraction."

Of course not. It is about the right level of abstraction.

Abstracting all the details away, I do not need to accomplish the task at hand.

If done right, this also will not slow things down, rather the opposite. Imagine programming a button in assembler and opengl. There you have all the details (and power). But chances are, you will be way slower and with a worse result, because you have to focus on other details and not on the task at hand.

Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing.

At best, it allows you to defer the deeper reading for a time. You might not even have to do the deeper reading for this piece of functionality, but the time will come when you have to figure out where an impedance mismatch is.

This quest for abstraction is the most infantile attitude I straw to squash in ever developer I meet. If you aren't reading the code that your code depends on to work, you have no idea what you're actually doing.

"Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing."

Erm, a beginner who wants to place a button that calls his defined method foo, really does not need to know about all the framework details to get the job done.

When I was a beginner, I was happy that I could place a button and link it with whatever with ease and it worked!

I simply did not needed to know about event loops, rendering algorithms, or internals of the framework. Now I happen to know quite a lot about it, because I designed a UI framework from scratch to solve a custom need.

But most use cases with UI are to display text, images and give text input and buttons. Ordinary programmers should be able to do that, without having to learn the graphic stack. Thats why we have frameworks. They just could be easier with better tooling.

Not wanting to pay for tooling is the major culprit.

One can pay for a CRM like Sitecore, AEM, low code like Outsystems, or enjoy the freedom of manually glueing HTML, JavaScript and JSS.

I've used UE4 for years and the Blueprints system doesn't save you much. Those abstractions are bricks, made for building brick houses. If you want to build something made out of anything other than brick, you're back to custom HLSL nodes and better off programming your shader somewhere else.

Blueprints are nicer for known problems, they are a better glue for old knowledge, but when you want to do something custom or new, you're out of luck.

This is the same problem with all programming, you can't make something specific and new without doing an engine teardown and rebuilding it. All the parts are terminally interconnected and always will be.

At the end of the day, UE4/5 is a landing pad for all the work you make in other tools. I agree web dev is no fun though.

Ironically, I know everything from ASM to...well many languages, including C, C++, PHP, Python, Ruby, Javascript, etc.

The most productive tools I used prior to learning all of that? HyperCard on the Mac, Visual Basic on Windows. Why? Tooling. Even when you had to get down and dirty, it seemed the tooling helped you out in some way. Shoot, I wrote an application back in the 90s in VB6 that still is functional TODAY not just in Windows, but in Linux and MacOS (thanks to translation layers such as Wine)

The same can NOT be said for the game I made in C++/OpenGL later...

I have personally never regretted using tools that were dismissed as "toys" by the mainstream devs. Including HC, VB, and Arduino. I've got a VB5 program running in the factory that has had virtually zero failures in use for 14 years. I even hand-translated a curve fitting routine from Numerical Recipes into VB.

What angers me on Windows world is how the WinDev team routinely sabotages VB and C# efforts to be back to those productive flow in graphics programming on the platform.

Managed Direct X, XNA, all killed when their advocates gave up fighting for them.

Nowadays they proudly refer to Unity when one complains about missing .NET bindings to DirectX.

JavaScript's Standard Library is basically NodeJS + Browser WebAPI's.

UI libraries/toolkits were really only considered a part of any standard library in like one language, (Java) which is still a stretch, because even Seing and AWT were toolkits.

Standard libraries are small. That's the point. You use primitives to build up the rest.

> JavaScript has no standard library.

    >> Math.sin(1.57)
    0.9999996829318346

This would be pretty surprising output if there were no standard library.

I think the gp meant standard UI library...

There's a standard library for that, too, but it's not exactly high-level.

https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...

At a higher level, that's pretty much what React is.

it's a bit exaggerated, but it's true that the standard built-ins for javascript is poor compared to something like java.

That's hard to argue with, though Java isn't known for convenient UI development either.

what languages are known for convenient UI development?

The sum language of HTML+JS+CSS, or in other words html files. I haven't seen a better way to write UI in text files, other UI frameworks relies a lot on building the UI in some special editor or aren't easy to use.

HTML as a UI is geared towards making documents and displaying text and graphics in a rigid layout/format.

It's not geared, imho, for a UI with lots of interactivity - e.g., imagine trying to implement blender or an audio processing app (like audacity) in html/css. You'd basically be creating new primitives on top of html, and build your UI on that (or install one of those UI libraries that _renders_ to html).

SVG is part of HTML and good for most of the needs except for the audio wave stuff (which Delphi couldn't do either)

well it depends on what you mean by convenient - java's got a UI toolkit that works out of the box for all supported environments (awt), and ontop of that is built a fair number of UI frameworks like swing (which is also part of the java standard library).

> java's got a UI toolkit that works out of the box for all supported environments

That's not a useful observation; JavaScript has that too.

> and ontop of that is built a fair number of UI frameworks like swing

Swing is what I was thinking of; I've never gotten the impression that anyone liked it.

"No standard library" might be too strong a criticism, but "a dozen or so built-in global variables with various methods" is still probably not the user experience that most desire.

What would you put in the JavaScript library?

No one ever needed a `leftpad` for strings.

See Python (for feature rich version) or Rust (for less feature rich standard lib).

"A dozen or so built-in global variables with various methods" is exactly what a standard library is. (Well, usually it's more than 'a dozen or so'.) Generally those variables are of the "package" type, but no such type exists in JavaScript.

Reminds of my time doing WebObjects development, and I fully agree that it seems like the frameworks I use today ( ReactJS, FeathersJS) aren’t (yet?) as simple to visually develop.