Earlier quoted context omitted.
> So I need a graphics designer to make a symbol for a card. I think this is the crux of the debate. The point isn't high quality visualizations, it's about bringing the simple little pictures you'd draw to solve your problem directly into the environment. Can you draw a box and put some text in it? Tada! Your own little representation of a card. I'm not suggesting that you hire people out to build your representatio…
Just use Unicode, and a programming language that uses the full power of Unicode symbology in its syntax. E.g. ♠♣♥♦ × A23456789TJQK
Toward a better programming
141–150 of 191 posts
Re: Toward a better programming
#142I 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…
Re: Toward a better programming
#143I really liked this. But I think we're encoding work, not thought.
If I could add to the list of hard problems: cache invalidation, naming things, encoding things.
I think the problem in a lot of cases is that the language came first, then the problem/domain familiarity comes later. When your language lines up with your problem, it's just a matter of implementing the language. Your algorithms then don't change over time, just the quality of that DSL's implementation.
Re: Toward a better programming
#144Earlier quoted context omitted.
> ...while discussing pointers and garbage collection and optimizing heap allocation People still do that? We still use 'if' and 'then', but higher level languages like Ruby and Python have eliminated pointers and their ilk from day-to-day discussion, relegating heap allocation discussion to the halls of specialized conferences, while many programmers go about their day-to-day activities skipping over the pain of gar…
> People still do that? Yeah, we do. Somebody has to manage all that memory that you throw around in your ruby/python scripts.
Somebody has to design and engineer the hardware and every level of abstraction between that hardware and whatever abstraction layer the "average" developer uses.
Re: Toward a better programming
#1451: Why can't we use standard mathematical notation instead of strings of ASCII?
2: Why do we need lots of control flow and libraries when implementing a mathematical equation as an algorithm.
The first is simple: as others have pointed out here, math notation is too irregular and informal to make a programming language out of it.
The second is more important. In pretty much any programming language I can write:
d = sqrt (b^2 - 4*a*c)
x1 = (-b + d)/(2*a)
x2 = (-b - d)/(2*a)
which is a term-by-term translation of the quadratic equation. But when I want to write this in C++ I need a loop to evaluate the sigma term.But in Haskell I can write this:
stDev :: [Double] -> Double
stDev xs = sqrt((1/(n-1)) * sum (map (\x -> (x-m)^2)) xs)
where
n = fromIntegral $ length xs
m = sum xs / n
This is a term-by-term translation of the formula, in the same way that the quadratic example was. Just as I use "sqrt" instead of the square root sign I use "sum" instead of sigma and "map" with a lambda expression to capture the internal expression.Experienced programmers will note that this is an inefficient implementation because it iterates over the list three times, which illustrates the other problem with using mathematics; the most efficient algorithm is often not the most elegant one to write down.
Re: Toward a better programming
#146Earlier quoted context omitted.
Just use Unicode, and a programming language that uses the full power of Unicode symbology in its syntax. E.g. ♠♣♥♦ × A23456789TJQK
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…
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 used to enter them. Perhaps that's the best way to go?
Re: Toward a better programming
#147This strikes me as armchair philosophizing about the nature of programming language design. Programming languages are not intentionally complex in most cases, they're complex because the problems they solve are genuinely hard and not because we've artificially made them that way. There is always a need for two types of languages, higher level domain languages and general purpose languages. Building general purpose la…
I have a ServiceControllerServiceProvider which disagrees.
Re: Toward a better programming
#148I 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…
That's pretty much the thesis of Bret Victor's "The Future of Programming" talk. It's here, for all who have missed it: http://worrydream.com/dbx/
Re: Toward a better programming
#149Earlier 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…
[X] I don't presume to know -- it's just the first system I came into contact with which has this concept.
(edit: apparently there's some magic markup I don't yet understand.)
Re: Toward a better programming
#150There's a reason the game Pictionary is hard, despite the "a picture is worth a thousand words" saying. And that is that images, while evocative, are not very precise. Try to draw how you feel. If you are using card[0][12] to refer to Card::AceSpades, well, time to learn enums or named constants. If, on the other hand, the array can be sorted, shuffled, and so on, what value is it to show an image of a specific state…
Part of programming is communicating thoughts. Plain text is great for that - we all read and write text. I also think it's easier to type "sqrt" or "sum", than to right-click, scroll through a pop-up menu and select the symbol I want. I suppose symbols can help one verify they've written what they intended if the environment supports translating "sqrt" and other functions into symbols that stretch over and around variables and other equations, but that's not what was demonstrated.
Finally, as others have pointed out, the mathematical expression of an algorithm doesn't necessarily lead to an efficient one.