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

81–90 of 191 posts

Re: Toward a better programming

#81

Post by ibdknox »

seanmcdirmid wrote: post #78
jamii wrote: post #61

Earlier quoted context omitted.

The problem with code as text is not the visual representation but the manipulation. From the point of view of tooling for live-coding, it's incredibly painful to deal with an unstructured pile of text that at any given point may be in an invalid state (ie partially edited). Structured editing ( http://en.wikipedia.org/wiki/Structure_editor ) allows the tooling to deal with consistent, structured data whilst still ta…

It's actually not that hard to deal with text, even in partially edited states. It's just most people don't know how to build a decent incremental parser with fairly good error recovery, but some of us do.

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 a file and now that's gone, but there's a function "bar" in the same place with roughly the same code, does that mean it was renamed? Or did foo get deleted and we need to surface that anything using foo is an error? How would you know? The only thing you have to go on is position and position can change for all sorts of other reasons. I ran into this problem with trying to do functions in single editors: when the file can change in any way, reconciling that file with your previous view of the world is tremendously difficult.

Re: Toward a better programming

#82

Post by jeorgun »

sold wrote: post #33

The standard deviation is a poor example IMO, in many languages you can get much closer to mathematical notation. def stddev(x): avg = sum(x)/len(x) return sqrt(sum((xi-avg)**2 for xi in x) / len(x)) stddev xs = let avg = sum xs / length xs in sqrt $ sum [(x-avg)**2 | x

It's even a poor example of C++. Using valarray, you end up with basically the same thing as your above examples:

    #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
…and none of those are really much less readable than the math version. All in all, that "example" clearly wasn't made in good faith, and left a bad taste in my mouth.

Re: Toward a better programming

#83

Post by misuba »

jimmaswell wrote: post #63
falcolas wrote: post #49

Earlier quoted context omitted.

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

>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. I can't see any issue with representing logic abstractly with symbols. It's the same for calculus. Of course the ideas we're representing aren't actually the things we use to represent them, the same as written communication…

> 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 operating a computer that help us see.

Re: Toward a better programming

#84

Post by jamii »

ilaksh wrote: post #73

I have been saying stuff like this for years, although not as eloquently or detailed. But now Chris Granger is saying it, and no one can say he's not a "real" programmer, so you have to listen. I think it boils down to a cultural failure, like the article mentions at the end. For example, I am a programmer myself. Which means that I generate and work with lots of static, cryptic colorful ASCII text program sources. I…

> I wonder if the current version of Aurora derives any inspiration from "intentional programming"?

The long term vision definitely does. At the moment we are mostly focused on building a good glue language. By itself it is already very capable for building CRUD apps and reactive UIs. If we can nail the tooling and make it as approachable as excel then that gives us a solid platform for more adventurous research.

Re: Toward a better programming

#85

Post by qnaal »

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 implementations and code snippets for every kind of project that's ever been worked on, at your fingertips.

Discussing how we might want slightly better ways to write and view the code we have written is ignoring the elephant problem- that everything you write has probably been written cleaner and more efficiently several times before.

If you don't think that's fucked up, think about this: The only reason to lock down your code is an economic one, despite that all the code being made freely usable would massively increase the total economic value of the software ecosystem.

Re: Toward a better programming

#86

Post by AdrianRossouw »

man. i've been thinking about this stuff a lot.

especially after I saw rich hickey's presentation "simple made easy" (my notes on it [1]).

I'm actually on a mission now to find ways to do things that are more straight forward. One of my finds is [2] 'microservices', which I think will resonate with how I perceive software these days.

[1] http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de... [2] http://martinfowler.com/articles/microservices.html

Re: Toward a better programming

#87

Post by nubbee »

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…

Memory is linear and so is execution( at a basic level ) yet our programming and ideas are not. Imagine programming as a needle with one continues thread stringing boxed functions and values together, sometimes threading something that has been threaded before, and ultimately creating a crisscross of wire that's hard to understand. We cannot organize something that is linear with a non-linear representation. We try to make the crossed wire simpler to understand with programming languages but it is inherently unsolvable as a problem. There will never be a authoritative programming language.

Re: Toward a better programming

#88

Post by AdrianRossouw »

deckiedan wrote: post #45
jimmaswell wrote: post #29

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…

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…

is that really better though ?

not today, but in 5, 10, 20 years from now.

Recent experiences have shown me that flowchart systems are really really specialized tools that require a lot of training to be able to use with a modicum of success.

There are very few problem domains where I believe they provide a more accessible and expressive solution than plaintext.

Re: Toward a better programming

#89

Post by jamii »

jonathanedwards wrote: post #68
ibdknox wrote: post #25

Earlier quoted context omitted.

The clever part of the strategy I was using in that demo was that all domains are expressed declaratively as datastructures. This meant that the glue language only needed to be very good at manipulating vectors and maps. You built up a structure that represented music, html, or whatever and then just labeled it as such. Interop between domains then becomes pretty simplistic data transformation from one domain's forma…

Here's some meat. So how does FP fall down?

Explicitly managing hierarchical data structures leads to a lot of code that isn't directly related to the problem at hand. A lot of attention is dedicated to finding the correct place to put your data. Compared to eg relational or graph data models, where that kind of denormalisation is understood to be an optimisation made at the expense of program clarity / flexibility.

The pervasive use of ordering in functional programming inhibits composition. (Even in lazy languages the order of function application is important). Compare to eg Glitch or Bloom where different pieces of functionality can be combined without regard for order of execution/application. This better enables the ideals that BOT was reaching for - programming via composition of behaviour. In a BOT plugin you can not only add behaviour but remove/override other behaviours which turns out to be very valuable for flexible modification of Light Table.

A more concrete problem is displaying and explaining nested scope, closures and shadowing. As a programmer I have internalised those ideas to the point that they seem obvious and natural but when we showed our prototypes to people it was an endless source of confusion.

Functional programming is certainly a good model for expressing computation but for a glue language the hard problems are coordination and state management. We're now leaning more towards the ideals in functional-relational programming where reactivity, coordination and state management are handled by a data-centric glue language while computation is handed off to some other partner language.

Re: Toward a better programming

#90

Post by sparkie »

JoelOtter wrote: post #50

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

I think you could broaden your horizons and try something other than imperative programming language on a von-Neumann machine, perhaps. Knowing how the machine works can be useful if you're working on low level stuff where efficiency is a priority - but that's only a small subset of programming problems - most people don't care about the how or how fast - they simply want to convert some user input to some pixels or files in various ways - and the abstractions they should be using for that are user inputs, pixels and files - not interrupts, registers and pointers.

A kind of obvious point on where having a knowledge of internals doesn't really help much is doing any kind of concurrent programming at scale. If you attempt to solve race conditions with the mindset of "knowing how the machine works", you end up inventing fences, mutexes, semaphores and monitors. (And OK, these are useful tools, and have been generally sufficient until recently - but they simply don't scale.) Compare this with something like Erlang's concurrency model - that of having many individual processes communicate through message passing (ie, the actor model), and it becomes much simpler to reason about concurrency (perhaps at the cost of efficiency, but as previously mentioned, that only matters in few cases). Erlang's model is abstract and says nothing about the machine on which it runs - and an existing knowledge of languages like C doesn't help a great deal to learning it over no programming experience at all.

Think of specialized being the antonym of of abstract, and consider that's what you are - a specialist - your skills are relevant for a specialized field, of implementing efficient programs on specific machines - but what OP wants to do is make programming available to anyone, as a general skill - he doesn't want everyone to become specialists at programming von-Neumann machines.

Post reply on HN