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.
Programming breakthroughs we need
421–430 of 511 posts
Re: Programming breakthroughs we need
#422As 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…
Re: Programming breakthroughs we need
#423Earlier 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.
Re: Programming breakthroughs we need
#424Earlier 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…
Re: Programming breakthroughs we need
#425I 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.
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
#426Earlier 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?
Re: Programming breakthroughs we need
#427Earlier 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…
Re: Programming breakthroughs we need
#428Earlier 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…
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
#429I 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…
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
#430Programming 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…
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)