I hope the production release will be editable by keyboard alone, instead of needing the mouse for every little thing.
Toward a better programming
41–50 of 191 posts
Re: Toward a better programming
#42Earlier quoted context omitted.
"[Graphical languages] work extremely well as limited languages for very constrained problems" Even that might need a citation...
[I'm curious why I got downvoted above - did I miss something?] I don't think that needs a citation though. Any GUI is a graphical language for a constrained problem. I could use a generic text language to post this comment to HN, or I can use a specialized graphical language that provides me with this resizable text input box and reply button. It's extremely constrained in this case. If it had GUI elements for doing…
"Any GUI is a graphical language for a constrained problem."
With that broad a definition (and I don't think it's horribly unreasonable), I agree it doesn't need a citation (even if I think GUIs are overapplied).
Re: Toward a better programming
#43I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere. On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI. On the negative side, there seems to be a huge amount of stagnation in…
I tend to think of it as evolution: new ideas that succeed and improve performance multiply, new ideas that fail disappear, and old ideas that are still efficient live on.
People still typing the same Unix commands into terminals do it because it's still the most efficient way to accomplish those things. Maybe it's always going to be the optimal solution for some tasks.
Just because an idea is old, doesn't mean it's bad or wrong.
Re: Toward a better programming
#44Earlier quoted context omitted.
"[Graphical languages] work extremely well as limited languages for very constrained problems" Even that might need a citation...
A few examples of graphical programming languages are LabView, Scratch, and Lego Mindstorms (NXT). (I'm not advocating graphical programming, just providing examples.) Edit: maybe graphical GUI editors such as in Xcode and Visual Studio could be considered tools for programming languages that are partially graphical and partially text based.
Yeah, I'm most familiar with graphical programming by way of hearing people complain about LabView.
Re: Toward a better programming
#45I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere. On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI. On the negative side, there seems to be a huge amount of stagnation in…
> People are still typing the same Unix commands into 25x80 terminal windows. People are still using vi to edit programs as sequential lines of text in files using languages from the 80s (C++) or 90s (Java). Well yes, there are always people who stick to the older methods, or sometimes the situation calls for programming through a terminal window, but there have been big advancements since those methods, like the gre…
That's kind of the thing... that there are other ways of programming (IDE instead of text editor), but for interesting languages, there's no clear cut proof that IDEs are actually better.
For languages specifically such as Java, which have very verbose syntax, and huge amounts of boilerplate for large projects, then sure, an IDE is an improvement.
But even IDEs, really, haven't much changed. And the fact that we even still can have the discussion, sort of proves that it's not that much of an improvement.
The core of his argument was the sequential text in 20+ year-old languages.
A radical change would be similar to how 3d materials & render chains have improved in the last 20 years. From editing Renderman text files, to the nodes system: https://www.google.co.uk/search?q=blender+render+nodes That's a radical shift.
Re: Toward a better programming
#46I hope the production release will be editable by keyboard alone, instead of needing the mouse for every little thing.
that prototype is basically nothing like what the end result will be. And yeah, it will be keyboardable :)
Re: Toward a better programming
#47I'm wondering, did the author ever play with Smalltalk/Self? Essentially those environments let you interact with objects directly, in about as much as makes sense. Seems a good fit for the "card game" complaint.
Doesn't help with the mathematical notation, though (Although it would be possible to do something about that, I suppose).
Re: Toward a better programming
#48I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere. On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI. On the negative side, there seems to be a huge amount of stagnation in…
I tend to think of it as evolution: new ideas that succeed and improve performance multiply, new ideas that fail disappear, and old ideas that are still efficient live on. People still typing the same Unix commands into terminals do it because it's still the most efficient way to accomplish those things. Maybe it's always going to be the optimal solution for some tasks. Just because an idea is old, doesn't mean it's…
Text as code, for instance, is just an extension of a concept which has been around in one form or another since the scribes of ancient Babylon, or thereabouts. I can imagine more complex ways of representing code but I can't really imagine anything more efficient for translating human concepts into machine language. Except maybe direct, augmented telepathy, but even then people would probably think to the computer in glyphs and symbols. Complexity doesn't always correlate with advancement.
Re: Toward a better programming
#49I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere. On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI. On the negative side, there seems to be a huge amount of stagnation in…
> People are still typing the same Unix commands into 25x80 terminal windows. People are still using vi to edit programs as sequential lines of text in files using languages from the 80s (C++) or 90s (Java). Well yes, there are always people who stick to the older methods, or sometimes the situation calls for programming through a terminal window, but there have been big advancements since those methods, like the gre…
> Why do you say programming has gone nowhere because there are people who don't use the newer advancements?
Speaking for myself, its because Visual Studio and its ilk don't feel like advancements. They feel like bandaids. They do their damnedest to reduce the pain of programming by automatically producing boilerplate, auto completing words, providing documentation, and providing dozens of ways to jump around text files.
Personally, I don't feel that the bandaid does enough to justify using it (granted, my main language doesn't work well with Visual Studio, so there's that too).
The main source of the pain is, to me, is that we're still working strictly with textual representations of non-textual concepts and logic, no matter how those concepts might better be rendered. We're still writing `if` and `while` and `for` and `int` and `char` while discussing pointers and garbage collection and optimizing heap allocation... Instead of solving the problem, we're stuck down describing actions and formulas to the machinery. No IDE does anything to actually address that problem.
Sorry, rant, but this problem certainly resonates with me.
Re: Toward a better programming
#50Forgive me if my understanding is totally out of whack, but it seems here that the writer is calling for an additional layer of abstraction in programming - type systems being an example.
While in some cases that would be great, I'm not entirely sure more abstraction is what I want. Having a decent understanding of the different layers involved, from logic gates right up to high-level languages, has helped me tremendously as a programmer. For example, when writing in C, because I know some of the optimisations GCC makes, I know where to sacrifice efficiency for readability because the compiler will optimise it out anyway. I would worry that adding more abstraction will create more excuses not to delve into the inner workings, which wouldn't be to a programmer's benefit. Interested to hear thoughts on this!