Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toward a better programming

chris-granger.com

Post reply on HN
Print view View original

151–160 of 191 posts

Re: Toward a better programming

#151

Post by lomnakkus »

kens wrote: 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 language semantics -- I can trivially write a program that (theoretically) calculates a number too large to represent in the number of atoms in the universe.

The command line amplifies (non-linearly) what you can conventionally do with simple UIs. As a trivial example:

    $ mkdir -p src/{main,test}/{scala,java,resources}
    $ touch src/{main,test}/{scala,java,resources}/.keep
I've just created 2*3 directories and files with two commands which were very quick to type out. I haven't done actual tests, but I'd argue that that was pretty quick compared to doing it in a GUI (for instance).

Re: Toward a better programming

#152

Post by zapov »

As someone who is trying to improve the situation (https://dsl-platform.com) it's strange getting feedback from other developers. While we are obviously not very good at marketing, when you talk to other developers about programming done on a higher level of abstraction usual responses are:

* I'm not interested in your framework (even if it's not a framework) * so you've built another ORM just like many before you (even if there is no ORM inside it) * not interested in your language, I can get most of what I need writing comments in php (even if it's not remotely the same)

It takes a lot of time to transfer some of the ideas and benefits to the other side and no, you can't do it in a one minute pitch that average developer can relate to.

Re: Toward a better programming

#154

Post by lomnakkus »

DanielRibeiro wrote: post #136
ibdknox wrote: post #81

Earlier quoted context omitted.

But the hard part isn't dealing with invalid parses and error recovery. The hard part is dealing with completely valid bits of code that aren't yet finished: (doseq [x (range|cursor|)] ) You can wait until the end of time, but that won't finish ;) Whereas I probably wanted to get out (range 10) before it went off and looped forever. Text also doesn't provide you with stable IDs. If I previously had function "foo" in…

I agree that the problem is not error recovery, but is more generaly described by Peter Naur's "Programming as Theory Building"[1]. With that, programming is hard because creating a theory, collectively, and teaching other people about it, is hard. Making it easier is therefore solving the problem Douglas Engelbart envisioned solving: Augmenting the Human Intellect [1] http://catenary.wordpress.com/2011/04/19/naurs-p…

I apologize for the fanboy post in advance, but Peter Naur was such a badass.

Re: Toward a better programming

#155

Post by tonyedgecombe »

qnaal wrote: post #85

Hate to break it to you people, but rms was always right- the #1 reason why programming sucks is that everyone wants complete control over all of the bullshit they threw together and thought they could sell. Imagine an environment like a lisp machine, where all the code you run is open and available for you to inspect and edit. Imagine a vast indexed, cross-referenced, and mass-moderated collection of algorithm imple…

Locking down my code for economic reasons has worked pretty well for me. It's allowed me to have a pretty good lifestyle running my business for the last fifteen years and kept my customers happy because they know I have a financial incentive to keep maintaining my products.

Re: Toward a better programming

#156

Post by Pacabel »

vorg wrote: post #146
mercurial wrote: post #139

Earlier quoted context omitted.

Please don't. People are already terrible at naming things, I for one am not going to try the entire Unicode table to find out which symbol you chose for "MetadataService". Plain text is fine, it's searchable, readable, and somewhat portable (minus the line ending debacle). If you need something more, vim has the "conceal" feature which can be used to replace (on the lines the cursor is not on) a given text with anot…

> vim can be used to replace a given text with another (eg show ⟹ instead of =>) If you use the short ⇒ to substitute for => (rather than long ⟹ as in your example), as well as many other Unicode symbols, then the overall code can be much shorter and thus more understandable. The spec for the Fortress programming language made a point of not distinguishing between Unicode tokens in the program text and the ASCII keys…

Why do you think that "much shorter" implies "more understandable"?

I think we have a lot of experience to suggest otherwise.

Anyone who has had to maintain old Fortran or C code will likely know what I mean. With some early implementations limiting variable and function identifiers to 8 characters or less, we'd see a proliferation of short identifiers used. Such code is by far some of the hardest to work with due to variable and function names that are short to the point of being almost meaningless.

Then there are languages like APL and Perl, which make extensive use of symbols. APL has seen very limited use, and Perl code is well-known for suffering from maintenance issues unless extreme care is taken when initially creating the code.

Balance is probably best. We don't want excessively long identifiers like is often the case in Java, but we surely don't want excessively short ones, either.

Re: Toward a better programming

#158

Post by mercurial »

Pacabel wrote: post #156
vorg wrote: post #146

Earlier quoted context omitted.

> vim can be used to replace a given text with another (eg show ⟹ instead of =>) If you use the short ⇒ to substitute for => (rather than long ⟹ as in your example), as well as many other Unicode symbols, then the overall code can be much shorter and thus more understandable. The spec for the Fortress programming language made a point of not distinguishing between Unicode tokens in the program text and the ASCII keys…

Why do you think that "much shorter" implies "more understandable"? I think we have a lot of experience to suggest otherwise. Anyone who has had to maintain old Fortran or C code will likely know what I mean. With some early implementations limiting variable and function identifiers to 8 characters or less, we'd see a proliferation of short identifiers used. Such code is by far some of the hardest to work with due to…

As somebody who spent some years writing Perl code, I don't feel that having a few well-defined ASCII symbols were such an issue. The problems with Perl are that symbols change depending on the context (eg, an array @items needs to be accessed via $items[$i] to get an item at position $i, to tell Perl it is a scalar context), and weak typing. Even with changing symbols, it makes it easier to distinguish between scalars, arrays and hashes, especially with syntax highlighting. As opposed to languages like Haskell or Scala, in which library designers are free to display their creativity with such immediately obvious operators as '$$+-'.

Edited to add that I agree with your overall point. Shorter is not always clearer. It can be a benefit to have a few Unicode symbols displayed via 'conceal' but it's not (at least in my experience) a major productivity gain. And the number needs to be kept small. If I want Unicode symbol soup, I'll play a roguelike.

Re: Toward a better programming

#159

Post by commlink »

krapp wrote: post #48
wvenable wrote: post #43

Earlier quoted context omitted.

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

I once had the pleasure of asking Marvin Minsky if he thought we'd ever use something other than text to create computer programs. Without missing a beat he said, "If it's good enough for Plato and Aristotle, it's good enough for me."

Re: Toward a better programming

#160

Post by pjmlp »

lomnakkus wrote: post #149
pjmlp wrote: post #131

Earlier quoted context omitted.

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

Mathematica may have pioneered the notebook[X], but there are imitations[1] which are arguably just as good (or better given the seeming ad-hoc nature of the Mathematica language). [X] I don't presume to know -- it's just the first system I came into contact with which has this concept. [1] http://ipython.org/ (edit: apparently there's some magic markup I don't yet understand.)

> I don't presume to know -- it's just the first system I came into contact with which has this concept.

It was already present on the Xerox PARC systems.

You can see a little bit of it here about Symbiotics, http://www.loper-os.org/?p=932 at minute at minute 30.

Or here for Smalltalk-80, https://www.youtube.com/watch?v=JLPiMl8XUKU

Post reply on HN