Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

421–430 of 511 posts

Re: Programming breakthroughs we need

#421

Earlier quoted context omitted.

>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.

Re: Programming breakthroughs we need

#422

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

I get your and the article's drift, but saying it won't come to pass because of grumpy programmers is IMO a bit unfair. I believe it'll come to pass, but it'll take a while because there's not a huge need for it right now. I believe the whole computing ecosystem is very shallow at the moment. There are lots of tools and lots of programming languages, but they are all shockingly similar. There is just too much monocul…

A monoculture is a sign of maturity. In the past, most programming languages were awful in one way or another. Whether it was C, Fortran, APL, Prolog, COBOL, Basic, etc -- all uniquely terrible. But now every programming language is pretty decent.

Re: Programming breakthroughs we need

#423
post #384

Earlier quoted context omitted.

> JavaScript has no standard library. >> Math.sin(1.57) 0.9999996829318346 This would be pretty surprising output if there were no standard library.

"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.

"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.

Re: Programming breakthroughs we need

#424
post #63

Earlier quoted context omitted.

yes. I wish I could somehow get to work on a blend between: a decompiler, debugger, emulator, static analyzer, memory profiler, and so on. The idea being some kind of a runtime for assembly code which does not actually execute the program but allows one to understand it in different sematinc levels, or dunno.. this is a very raw idea. needs a lot of work (and a lot more knowldedge) to set down. too bad none of the pr…

I think dynamic analysis is incredibly powerful and criminally underused in IDEs and other dev tools. I have thought of an idea about 6 months ago that has been fermenting in my mind since then : what if (e.g.) a Python VM had a mode where it records all type info of all identifiers as it executed the code and persisted this info into a standard format, later when you open a .py file in an IDE, all type info of the o…

Sounds smalltalk-y with a little more bolted on.

Re: Programming breakthroughs we need

#425
post #5

I would suggest to author to look at functional languages, like Haskell. These are based on principles of function composition and referential transparency. The move from testing to static analysis is happening there, in the expressiveness of the type system, and its inferences. Functional languages are on the forefront of experimentation with new type systems.

> The move from testing to static analysis Are you claiming that static analysis of code can replace the concept of writing tests completely? If so, I'm very skeptical.

Depends on the type of the test. The larger the system is, the more unexpected interactions can happen, and the more need for testing.

But if we are talking about unit test on the level of functions, yes, I think they can be replaced.

Re: Programming breakthroughs we need

#426
post #384

Earlier quoted context omitted.

"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.

Re: Programming breakthroughs we need

#427

Earlier quoted context omitted.

> for the contexts I care about (small web applications largely written by solo devs). found your source of disagreement. this is, generally, not the domain anyone writing languages cares about. no one writes a language for an individual.

> Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby. I didn't work hard to make Ruby perfect for everyone, because you feel differently from me. No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it's not perfect f…

Looking at the differences between Python and ABC (its predecessor), I would agree Mats' last sentence is entirely plausible.

Re: Programming breakthroughs we need

#428
post #400

Earlier quoted context omitted.

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…

> 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. Tha…

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!

Re: Programming breakthroughs we need

#429
post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. 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.…

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, ma…

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.

Re: Programming breakthroughs we need

#430

Programming has always been making really detailed instructions that tell machine what to do. The article could have been written in 1989, 1995, or 2005 and really been materially the same. Glue code, boilerplate, tests, frameworks, languages, and maintaining existing code all things that developers complain about. All things waiting for the next magical solution... We largely build software the same way with the sam…

> We've never found a way to program at a higher level

Compare 1950-1970 with 1980-now. We found a way to program at a higher level then; why shouldn't we be able to now?[0]

In the meantime, as a minor win, I'll note that most of my $WORK codebases in the XX were heavy on pointer[1] manipulation, while very few of them are in the XXI.

[0] let's hope the gap between structured programming and its replacement is not going to be as long as that between Euclid and Lobachevsky!

[1] "pointers are the goto of data structures" (bastardized Tony)

Post reply on HN