I'm concerned about Chris's desire to express mathematical formulas directly in an editing environment. Coming from a mathematician with more than enough programming experience under his belt, programming is far more rigorous than mathematics. The reason nobody writes math in code is not because of ASCII, and it's not even because of the low-level hardware as someone else mentioned. It's because math is so jam-packed…
The mathematical notation also lacks a lot of type information. Looking at his example formula, First of all, both x and N are magic variable names, where did they come from? Second, what happens if x is a string and + is considered string concatenation. Mathematical notation has all the problems of duck typing and even more. In a way that's also the beauty of math, you can multiply matrices with same rules you learn…
Toward a better programming
161–170 of 191 posts
Re: Toward a better programming
#162I 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…
Think about boiling water. You boil it till 100 Celsius scale. You keep heating it, but it won't attain more temperature, without turning it into steam. Now think about it, we do not need steam but we need liquid water for survival.
Re: Toward a better programming
#163Earlier quoted context omitted.
> 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 fi…
Re: Toward a better programming
#164Re: Toward a better programming
#165I 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…
Anyone who thinks it hasn't improved should take a look at the description of the program used as an example in David Parnas's classic 1972 paper 'On the Criteria to be Used in Decomposing Systems into Modules' ( https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit... )
It's a KWIC (keyword in context) program and he says a competent programmer should be able to code it in a week. These days it's about 5-10 minutes in Ruby or Perl.
Re: Toward a better programming
#166I 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). This seems like an almost willful misunderstanding of what programming is. The power of programs does NOT come from their syntactic structure. The power of programs comes from the non-linearity of programming lan…
Pictographs work for the illiterate, but that doesn't make them the most efficient interchange mechanism.
Re: Toward a better programming
#167Earlier quoted context omitted.
That doesn't sound convincing. The Xerox PARC GUI is everywhere . The results of their work are about as mainstream as they could possibly be. Likewise, Smalltalk and Mesa were both hugely influential in everything from C, C++, Java and beyond. Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield…
> The Xerox PARC GUI is everywhere Quoting Alan Kay Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world. > Given that, it seems more likely t…
He also goes on to praise NLS, which failed precisely because of its steep learning curve and unsuitability for large swaths of the personal computing market.
Incidentally, that's why a GUI with overlapping windows succeeded : because it was familiar, intuitive and simple.
IMO, it's rather telling that none of the major DE's or WM's involve automatic tiling. This, despite the fact that there are a myriad of solutions available [1]. It's not about "better" or "worse", but suitability for a given market.
[1] If anyone's interested, I highly recommend i3. As powerful as xmonad with a fraction of the configuration hassle.
Re: Toward a better programming
#168i think abstraction may correllate with a ide or librarys usefulness, popularity, and development time, moreso than what your video demonstrates.
i have a question, how many clicks would getting this snippet from above to work?
you also have to navigate various dropdown menus? (dropdowns are pretty terrible UI, and i would think reading diff dropdown lists im not familar with would be jarring.) IMHO it would be like writing software with 2 mouse buttons, dropdowns or other visual elements, and instead of with keyboard, and would actually be slower. the opposite of my point above
#include
#include
double standard_dev(const std::valarray &vals)
{
return sqrt(pow(vals - (vals.sum() / vals.size()), 2).sum() / vals.size());
}
int main()
{
std::cout Re: Toward a better programming
#169Re: Toward a better programming
#170Earlier quoted context omitted.
> I can't see any issue with representing logic abstractly with symbols. That's the problem: text isn't abstract enough. So we put some of the text into little blobs that have names (other methods), and use those names instead, and we call that "abstraction," but black-box abstraction doesn't help us see. The symbols in calculus, by contrast, are symbols that help you see. The OA is calling for abstractions over oper…
Agree. There is must be more abstract way to present ideas than text. In this way, programs are easier to understand and modification, and have less errors and bugs.
Written language is wonderful in many respects, and I sometimes thing people discount these things out of familiarity. Keyboards too- you can do things very quickly and very precisely with keyboards. Those things matter for your sense of productivity and satisfaction.