Live data from Hacker News

Toward a better programming

chris-granger.com

161–170 of 191 posts

Re: Toward a better programming

#161
post #134
post #98

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…

This. Types are the hardest thing about translating mathematics into programming. And it's really the fault mathematics (or a feature of it, depending on your viewpoint).

Re: Toward a better programming

#162
post #17

I 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 don't say this to counter your views, but I think there is a threshold limit in everyday life.

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

#163

Earlier 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…

Our ancestors used symbols to convey messages and logic. Then came the Phoenicians. Its their fault!

Re: Toward a better programming

#165
post #17

I 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 alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere.

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

#166
post #17

I 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…

One of my favorite CS professors back in the 80s used to joke that we had gone from cave paintings to written language, and now we wanted to back with our computers. (my paraphrase of whatever he actually said back then)

Pictographs work for the illiterate, but that doesn't make them the most efficient interchange mechanism.

Re: Toward a better programming

#167
post #131
post #99

Earlier 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…

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

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

#168
i have to disagree somewhat. imho the difference is in abstraction. i think good forms of abstraction have allowed computing proceed as far as it has, and will allow it to proceed further.

i 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

#170
post #83

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

I am suspicious. I think it would certainly be easier in some ways for rank beginners- it would make spelling errors and certain classes of syntax errors impossible- but those aren't really the bugs that cause experienced programmers grief. It's generally subtly bad logic, which is more about how people are terrible. Plus, we already know how to create computer languages that largely avoid those problems.

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.

Post reply on HN