> On Oct 29, 2016, at 12:40 AM, Rien <[email protected]> wrote:
>
> Hmm, I have engineering problems today. There will be engineering problems in
> 20 and 30 years as well, but I rather have a tool that is geared towards
> today’s problems. It would be even better if that tool is flexible enough so
> that it can adapt to the requirements as they change.
I have already given several examples of how this can be done using today’s
hardware (the TouchBar only makes things better). I have even shown how it can
work with plain old text editors. Sure, in the case of using a vanilla editor,
you lose some discoverability and ease, but that is a tradeoff that you make
for using a vanilla editor (everything is still possible). Programs like
BBEdit are infinitely extensible, and would quickly have plugins.
I agree that we want flexibility to adapt to requirements as they change.
> The difference between a puck and the future of engineering is that you can
> make a very good prediction about where a puck is going to be based on
> direction and speed. It is completely impossible to predict where the future
> of programming is going to be in 20 years time.
Sure you can. I have an extremely good track record of predictions (and a
horrible track record of being able to convince people before things actually
happen… I call it my Cassandra Complex). You can’t predict everything of
course, but there are patterns, trends and cycles that are fairly obvious if
you look for them. Look at how the kids today communicate… they will be
tomorrow’s programmers. I may not know exactly where we will end up, but I can
tell which way the wind is blowing. You can either embrace the wind or fight
it and be lost at sea.
More importantly though, we have a chance to help MAKE the future we want to
see. That is why we are all here. While I value forward transfer, growth
always requires some change.
Once again, I am not saying we should willy nilly replace things with crazy
symbols. I am saying we should feel free to use whatever is clearest and most
expressive for a given situation. If that is a word, we should use a word. If
it is a symbol, then we should use a symbol. If that symbol is ASCII, then so
be it. If it is unicode, we can do that now. Giving ourselves an artificial
constraint of only being able to use the characters which are painted on US
keyboards will, by definition, lead to a less clear/expressive experience.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution