|
You could e.g. look at CHILL, aka Z.200: Any block may have a handler attached: If there is an ON-clause between the body of the block and the terminating semicolon, the block has a hanlder. If there is no ON-clause, it does not have a handler. THere is no need to pre-announce it.
Note that in CHILL, as well as in most other sensible languages of the Algol class, a statement is a block; you don't need to enclose a single statement to make it one. So it would be like
CallSomeMethod();
CallSomeOtherMethod() -- note: no semicolon - block not yet complete
ON (SomeFunkyException):
LogThisException();
END; -- here is the semicolon terminating the block Usually when you want to attch a handler to a group of statements, that group is e.g. a function body, a loop, an if/then/else etc. defining a block. If these two calls are looped, and you want to attach the handler to the loop - i.e. the it is invoked when the exception breaks out of this loop, you would write it as
DO
CallSomeMethod();
CallSomeOtherMethod();
OD -- note: no semicolon; loop still incomplete
ON (SomeFunkyException): -- handler for exception in the loop statement
LogThisException();
END; The DO-OD bracing of the loop body makes it a block, to which a handler may be attached without any further blocking.
If you want to attach a handler to the two calls, not to the loop as such, you have to make them into block by bracing them:
DO WHILE ExceptionCount < 10;
SomeCallNotHanldedByTheOnClause();
BEGIN
CallSomeMethod();
CallSomeOtherMethod();
END -- no semicolon - handler follows
ON (SomeFunkyException): -- handler for exception in the loop statement
LogThisException();
Exceptioncount +:= 1;
END;
AnotherCallWithNoHandler();
OD;Now the handler for the two statements is processed within the loop, and unless another exception is caused, control stays within the loop.
CHILL uses keywords rather than braces; that is not the point here. Braces might have saved a few keystrokes, but since keywords often come in pairs, they do their own bracketing, like DO-OD, ON-END, ... You need to indicate which kind of block (like DO), and adding a brace to indicate "I am serious - a block!" is redundant. You could of course save a keystroke by replacing the OD with a closing brace, but I'd find it strange for braces not to come in pairs. I rather have an OD terminating a loop body, a FI terminating an IF statement and so on, documenting the type of block terminated, rather than a series of anonymous braces terminating a nest of blocks.
You could also note that the use of distinct keywords avoids a lot of other blurb, e.g.
BEGIN
CallSomeMethod();
CallSomeOtherMethod();
END
ON (SomeFunkyException): LogFunkyException(); Funkiness +:= 1;
(SomeStrangeException): LogStrangeException(); Strangeness +:= 1;
ELSE: LogOtherException(); EXIT SurroundingStatementLabel;
END; Each ON-alternative defines a block, with no further need to bracket multiple statements.
CHILL is a language that was actually designed - it didn't end up that way by random luck because the space invasion game presented a new wish that K or R sat down the same night to put into the compiler as best they could. It was known before the first implmentation begun that no bracing was required to add exception handling to a block. That no bracing was required for each on-alternative. And so on. Consequences of the overall language design was considered before the spec was frosen.
So it was someting like that detestable "waterfall model", we'll have to admit that. That is a good enough reason for rejecting the language design, and rather go for one wit a lot of syntatical workadounds, braces, paretheses, keywords to pre-anounce what comes later and whathaveyou.
But please do not confuse "ability to create ugly workarounds that make the language survive" with good design!
|
|
|
|
|
I must be missing something - with the exception (no pun intended!) of the single-statement / single-block case, why is:
BEGIN
...
END
ON (SomeFunkyException): ...
END; any better than:
try
{
...
}
catch (SomeFunkyException)
{
...
} Is it just the curly-braces you don't like? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yes, you are missing something.
The BEGIN-END really has nothing to do with the exception handling - it does NOT announce the ON. It just creates a block out of smaller ones. It has multiple uses; you could e.g. label the block, and skip out of it if some test is not satisfied, like
ManySteps:
BEGIN
Step1();
IF PreparationWentWrong THEN EXIT ManySteps;
Step2();
IF Specialcondition THEN EXIT ManySteps;
Step3();
END ManySteps; This is just a way to make a block that is not a loop, not a conditional statement, not a function body, but just a sequence of smaller blocks put togeteher for some purpose (such as here: For leaving, when conditions are right). Actually, I sometimes do something similar in C#, using a "do { ... } while (false);" to allow me many exits from the statement sequence without cdreating a deep nest of if-statements - but the C family allows just exiting the innermost block; in CHILL you can exit directly from any labeled surrounding block.
Whatever might be: The BEGIN-END has nothing to do with the try {...}. You may say that in CHILL, any block "implies a try {}".
I do not like redundant markup, whether extra keywords, braces, parentheses or whatever. If you say "Here come a DO-block" by using a DO keyword, then you should not need to add neither BEGIN nor a brace to say that "this is the block". Of course it is - you said so already! When you say "Here comes a conditional block" by using an IF keyword, you should not need to use an open parenthesis to say that "here comes the condition". Of course - how often do you see an if keyword not followed by a condition? So why do you have to announce it by opening a parentheses pair? In prose text, you never need to write the condition part of a question in parentheses, why do you have to in C?
If you want to treat two smaller blocks as one unit, whether for exception handling, exiting or whatever, one way or another you must identify which blocks you are talking about. THat markup is not redundant, whether it is done with keywords, braces or indentation alone. When you are comparing the try{} with the BEGIN-END, you are comparing apples with oranges, redundant with non-redundant markup. In C-style languages, the braces are there for the try (alone):
try {
SingleStatement();
}
catch ...Well, you could argue that in C languages, the parentheses are not redundant, as a single statement is not considered a block, so the braces are required to created on. That is a major flaw in the language "design". Conceptually, there it adds no information; the braces are conceptually redundant even though the syntax rules explain why they have to be there. In CHILL, there is no such need, neither for bracketing constructs nor for the try keyword.
Braces are fine for their brevity. But they are anonymous; they carry no distinguishing information neither to the compiler nor to the reader. At the end of a deep nest, in C languages there may be a lisp-like sequence of closing parentheses, and you may have a hard time seeing which one closes the outermost loop, the while, the function, the class... With a DO-OD, first, you need no redundant start-of-block brace, second, you know when you see the OD that this is not the end of the function or module or an if, but of the loop. If it is unclear which loop, you may label the statement and include the label after the OD, like I did with the END ManySteps; - this is optional, but if you use it, it is checked by the compiler.
Using OD rather than a closing brace also tells the compiler about your intention: It will match it up with the DO, and can therefore provide much better error reporting and error recovery so that it can go on with the parsing. If the compiler just sees a sequence of closing braces, it cannot tell which one is intended to match which opening brace. So, was the follwing statement intended to be part of the ELSE block? or the loop body? or...?
In my previous post I also illustrated how the explicitness of keywords makes extra bracketing of e.g. on-alternatives unneccessary; the keyword alone gives sufficient information.
For the BEGIN-END pair in particular, you might argue that no more information is added than with braces, so in that case you could use braces. But a mixture of some blocks being denoted by keywords, other by special symbols, looks rather messy. And, you do not that often need to combine an arbitrary sequence of smaller blocks (/statements) into a larger block: When you EXIT something, it is usually a loop, a function or something that is already a block and doesn't need any extra embracing. Same with exception handlers: You very often set them up for a function, a loop, a condition, or a single statement. For the quite few cases where you block up two or three statements for some purposes, you can affort that little handful of extra keystrokes. Especially considering the advantages to readability and improved compiler support.
|
|
|
|
|
Member 7989122 wrote: This is just a way to make a block that is not a loop, not a conditional statement, not a function body, but just a sequence of smaller blocks put togeteher for some purpose
You can create a similar block in C# using braces. And if you're particularly masochistic, you can mimic the EXIT with a goto[^]. 
ManySteps:
BEGIN
Step1();
IF PreparationWentWrong THEN EXIT ManySteps;
Step2();
IF Specialcondition THEN EXIT ManySteps;
Step3();
END ManySteps;
{
Step1();
if (PreparationWentWrong) goto ExitManySteps;
Step2();
if (Specialcondition) goto ExitManySteps;
Step3();
}
ExitManySteps: But this example would probably be better handled with SEH - if something went wrong, you don't want to depend on the caller checking a return value, or some unrelated property.
Member 7989122 wrote: When you say "Here comes a conditional block" by using an IF keyword, you should not need to use an open parenthesis to say that "here comes the condition".
That could potentially lead to ambiguity - which statement(s) are part of the condition, and which are part of the branch? Even if it's always obvious to the compiler, it may not always be obvious to the person reading the code. And the main point of any code is to be read and understood by a person.
Member 7989122 wrote: That is a major flaw in the language "design".
No, it's a major difference in the language design. (And yes, the language was designed. No need for the sarcisti-quotes.)
English doesn't have accents on any letters; you're just supposed to know how to pronounce them. Does that makes the accents in other languages a flaw? Or is English the flawed language for not having them?
Just because something is different doesn't mean that it's flawed.
Member 7989122 wrote: At the end of a deep nest, in C languages there may be a lisp-like sequence of closing parentheses, and you may have a hard time seeing which one closes the outermost loop, the while, the function, the class...
 Agreed. But code that's nested that deeply is crying out to be refactored anyway.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: And yes, the language was designed.
I'd certainly like to see those design documents. Which alternatives were considered, the rationale behind each, the arguments for the selected solution. I have never ever heard even the tiniest little suggestion that any such thing exists.
What was the rationale for not having a proper argument list in the function header, in the initial K&R, but listing the arguments below the header?
What was the arguments when the language was redesigned for changing it to how other Algol-class languages did it?
What was the rationale for not defining a statement to be a block, as in most other Algol-class languages?
What was the rationale for defining the syntax of conditional statements like while-loops and if-statements so that parentheses are required around the condition - it is not in languages like Pascal, CHILL, Algol?
What was the rationale for using the equals sign for assignment, so that an equals condition must be represented by two equals signs?
What was the rational for deviating from the ISO standard interpretation of the CR, LF and NUL character codes?
What was the rationale for not including enumeration types, as a first class type, in the language? For Algol-60, you can find discussions of it in the design douments, but lack of resources prevented them from implementing it time for the deadline, so it was omitted from the specificatin - but Pascal implemented it a few years later. Why didn't C?
This thread has said a lot about exception handling. The first generation of C/C++ execption handling was not part of the language definition, but a cludge realized by macros and longjmp so that programmers could pretend that C had the same facilites as (some) other languages. Was there a design document for this? Was there a design document specifying how to incorporate this cludge in the language itself?
Writing a book a couple of years after the implementation, to tell: See what we have implemented! - that is not a language design process.
Algol was through a design process. CHILL was through a design process, where several competing proposals were analyzed, and after critical evaluation of each feature, a choice was made to how it ws to be defined in the final specification. Starting with Fortran 77, Fortran has been further developed in a similar way, but of course with strong dependencies on earlier language versions.
SUN tried to make ISO accept Java as an ISO standard. But when they learned that they could not simply revise the standard themselves and slam the document on ISO's desk: Here is the new version!, but learned that there would be a committee to eavaluate the new features critically from various angels, designing a new version, then SUN retracted their application for ISO approval. They may have had similar internal evaluation and design rounds, but they were not willing to let others in, as ISO procedures demanded.
Nowadays, C/C++ revisions are into such a mill of critial evaluation, rational decisions and lots of people having their voice heard. Like Fortran, the legacy is heavy.
If you can give any pointers to sources documenting that legacy C, preceeding the ANSI approval was the subject of design, rationale and critical evaluation of alternatives, then I would certainly like to see it. I am not thinking of "I remember how it was back then...", but actual design documents, created at a time when the design was made, not as a history book looking back.
|
|
|
|
|
Going back to Kate's message that started this branch[^], we were talking about C#.
Since 2013, all C# design discussions have been public on GitHub:
GitHub - dotnet/csharplang: The official repo for the design of the C# programming language[^]
Earlier discussions were not made public, but some information was available on various MSDN blogs.
The language was originally designed by a team lead by Anders Hejlsberg.
As for C/C++, the details of those decisions are likely lost in the murky depths of the dim and distant past of 1972, unless Dennis Ritchie kept some notes somewhere.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Javascript is obviously dynamically typed - but as I gravitate towards statically typed languages, I'll go for a language like Ocaml, Haskell or F#. They all define record types similarly, but with slightly different keywords and syntax.
I'll give an example in Haskell:
data Location = Location { city :: String }
let home = Location { city = "Boston" }
and F#
type Location = { City : string }
let home = Location { City = "Boston" }
let other_home = {| City = "Boston" |}
johnywhy wrote: I mean, easy to understand at a glance.
I find Haskell's syntax pretty clear for pure functions. Having pattern matching brought out to the top level of function definitions makes it similar to have you might write a piece-wise definition of said function. Having function signatures be optional (the compiler will work out what the signature should be if you leave it out) leaves code less cluttered
factorial 1 = 1
factorial n = n * factorial (n-1)
list_length [] = 0
list_length (first_element:rest) = 1 + list_length rest
and F# again:
let rec fac n =
match n with
| 1 -> 1
| n -> n * fac (n-1)
let rec length list =
match list with
| [] -> 0
| first :: rest -> 1 + length rest
johnywhy wrote: What's "Concise"?
johnywhy wrote: What's "Practical"
I'll probably select F#. It's a .NET language, so can use .NET libraries. I like how the various features work together to provide powerful facilities with little code. An example - some code taken from the Microsoft website to download a bunch of URLs in parallel, with async/await
open System.Net
open Microsoft.FSharp.Control.WebExtensions
let urlList = [ "Microsoft.com", "http://www.microsoft.com/"
"MSDN", "http://msdn.microsoft.com/"
"Bing", "http://www.bing.com"
]
let fetchAsync(name, url:string) =
async {
try
let uri = new System.Uri(url)
let webClient = new WebClient()
let! html = webClient.AsyncDownloadString(uri)
printfn "Read %d characters for %s" html.Length name
with
| ex -> printfn "%s" (ex.Message);
}
let runAll() =
urlList
|> Seq.map fetchAsync
|> Async.Parallel
|> Async.RunSynchronously
|> ignore
runAll()
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Every professional program has 3 audiences:
1. the programmer
2. other programmers
3. the compiler
The "fantasy language" fails in all 3 areas:
1. Sure, right now the syntax makes perfect sense. But come back to the same code after a 6 month or even 2 year lapse? Every programmer (including me) I know looks at their own, older code with a "WTF was I doing?" expression on their face. Remove the keywords and punctuation and the problem gets a lot harder. Everyone thinks they'll remember exactly what they were doing at the time; 99%+ of us don't.
2. A professional program is highly likely to be supported (eventually) by at least one other programmer. The problems of point #1 are multiplied by 10 or even 100 because the second programmer has to figure things out. I've supported enough code to have a deep appreciation for well organized code that includes comments which explain "why" something is being done. My effort is reduced tremendously by those 2 things.
3. Use of "judicious" whitespace as syntax is a poor idea. Sure, the compiler can figure it out, but when the whitespace is wrong, the programmer cannot see the mistake. The real problem here is not compiler errors (which should point out the offending line so the programmer can [hopefully] figure it out), but when the program DOES compile and run, but produces wrong results.
The constant move towards conciseness is being taken to an extreme, and it's causing more problems than it is solving. The more concise the language, the steeper the learning curve, and the more prone to programmer errors, and those problems are harder to solve.
Programming languages are created for people, not computers. The computer runs machine code -- regardless of how the program starts, it ends up in machine code. Write your code so the someone else can figure things out in the least amount of time.
|
|
|
|
|
Let me explain to you the undesirability of you desire:
All that punctuation is to remove ambiguity.
You can play games and replace semicolons with new-lines, specific indent counts, whatever, and it's still the same. Is "Start->End" really better than "{->}". Neither logically nor visually.
If you have a block of code in a conditional you need some method to mark statements off as part of the block and not just the next statements to be executed after the conditional.
As for why things keep copying the 'C-like' structure? Not saying it's the end-all of design but it eliminates a lot of the absurd arbitrary. Like my first language, FORTRAN, having all statements start in column seven.
I find your javascript example ludicrous. You make the javaScript unnecessarily complex for the simple act of assigning a value to a symbol - but not in your dream version. Just to start.
Coming right down to it - human readable is a nebulous concept as you intend it. Mandarin is human readable - unless you don't know it. So is Hindi, Hebrew, and Arabic. Unless you are not accustomed to it. Those who speak these languages natively would differ with you strongly as to what is readable. Thus it is for a coding language. You learn to look at it and your eyes and brain will translate it. Meanwhile, the efficient interpretation of the syntax is guaranteed by the punctuation.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Well, just in terms of the JavaScript, here is how I would write it.
var home =
{
cit : "Boston"
};
home.city = function(aCity)
{
if (arguments.length)
this.cit = aCity;
else
return this.cit;
};
Yes, the function is a bit longer but there is only one function instead of two and writing pointless "get" and "set" is no longer necessary. That is a holdover from languages which do not have true getter / setter type attributes. I would note that the function would normally be part of a class (or prototype) and not the object itself.
In C++, it takes more work, but you can write code so that you can literally write
aCity = home.city;
home.city = aCity;
I usually don't do that, but I do do the same thing in C++ as in JavaScript. Note that brace placement may make it look longer, but that is matter of style. Braces are part of a statement block, so I indent the same as the statement block. And don't use unnecessary braces. The make code less readable.
I agree with you about APL not being readable. Perl has a lot of the same characteristics.
I disagree about COBOL, it is both far less concise and far less readable.
If something is too concise, it becomes unreadable. But, conversely, when it is too expansive (non-concise?) then it is also less readable. A straight mathematical expression whether in a conditional or an assignment is generally maximally readable. Assuming that the length and complexity of the expression is not too large. And that weird and strange operators (APL) are not in use.
So languages whose basic structure is similar to C tend to be most readable without becoming too concise.
|
|
|
|
|
A couple questions:
What is your audience? Non-technical average Joe? Technical (domain expert) but non-programmer? Software engineer? Firmware Engineer?, etc, etc, etc.
What is the target program type? Web? Windows/Linux application? Embedded realtime?, etc, etc, etc
I believe you're not going to find (or create) the 'perfect' language that's practical and concise that will handle all these user types and targets.
|
|
|
|
|
Kotlin: maybe not best "human-understandable" but it takes Java and make it more concise.
You don't have to write many things the Kotlin that you write in the Java.
Red: it's still in the alpha version but you should keep an eye on it.
You can write in different styles but you can write small & concise code. It has some "weird features".
Ruby: It might be not fastest language but it's very readable. No "parenthesis hell" (same as in the Red) as in other languages.
|
|
|
|
|
No one has mentioned Python?!? That's interesting.
|
|
|
|
|
That was exactly my thought, and I had to scroll down way too much to find this 
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread 
|
|
|
|
|
Why? Why optimize for concise? To save YOU time typing?
I write code in a pseudo code format for the first pass, then have to translate it to one of many languages depending on the target. Most concepts are clear enough.
What about R? (Functional languages?)
But again... I prefer a language that has the libraries/components/tools that I need.
If I gave you your "perfectly" concise language, without a bunch of caveats, like no libraries, no classes, no protocol support. Would you want to use it? If you had to implement AES, SMTP, HTTP, etc
all by hand?
==
The most important thing I ever learned... Once you know how to write the program properly. The language is not usually what is holding you back. Especially with UDFs.
==
For me. C was the most elegant language and always my favorite. It was PDP Macro Assembler as a language with indentation and code blocks, UDFs, etc. etc. And probably a bit too concise, LOL!
|
|
|
|
|
> Why optimize for concise? To save YOU time typing?
I don't think typing is a problem when you have IDEs with autocompletion.
The problem is reading. Sure, your IDE will colour this and that but you still have, for example, whole line just saying "<foo> is the name of the function".
|
|
|
|
|
I think of it more at a concept level rather than saving typing. Avoid reduncancy. Avoid tokens that serve no purpose. Remove clutter.
As I argued earlier in the thread: A language such as CHILL allows any block to have an exception handler attached. Putting "try{...}" around the block before the handler is redundant: If the handler is present, then the block has a handler - no need to pre-announce it! Removing the need for that pre-announcement simplifies the code.
(The real reason for the C/C++ try{} is purely historic: C didn't have any such thing, while several other languages did. So to "compete", a macro-based solution was devised, that required no extension to the underlaying compiler. When adopted into the C/C++ language, it could have been given a cleaner syntax, but to be backwards compatible with all the code that had been written for the macro-based implementation, the syntax was kept unchanged.)
In Pascal (or CHILL), you write a condtion without enclosing parethes like in prose text: If it is raining, then you better wear a raincoat. You need not clutter up that sentence with parentheses markup. You remove the conceptually informationless tokens.
var matching = new List<FileInfo>(); rather than
List<FileInfo> matching = new List<FileInfo>(); removes redundancy, risk of inconsistency, and the reader has fewer tokens to interpret. I do not see what we gain by repeating the type information when it can be infered. (var has other uses as well unrelated to this.)
A language recognizing a statement as a block avoids redundant bracketing: At the spur of the moment, I cannot think of a single case where single-statement block and a single statement are both valid but with different semantics. So I see no reason why some languages insist on adding these extra tokens that carry no semantic information.
The idea is that non-information-carrying elements (that you nevertheless have to relate to) are bad. The fewer elements you need to process mentally, the better.
This is, of course, assuming that the programmer/reader easily relates to the concepts repersented by the tokens. E.g. to a matehmatician, matrix inversion is such a basic and common concept that giving it a separate symbol (analogous to multiply and divide) as it done in APL (created as a mathematical notation, not as a programming languge) is perfectly fine even though non-mathmaticians says "Huh?". For those who are "only engineers", powers are essential, so languages with that user group in mind have a token for that operation (like 2**11 or 2^11); that simplifies and improves readability of engineering calculations, rather than "power(1, 11)". A low-level language for handling bit patterns does the same with left and right shift operators: There is no need for a symbolic function name, and parentheses around an argument, when you can simply write it as a double larger- or smaller-than sign. That removes clutter.
This kind of simplification, avoiding information-less elements, results in a consisness that eases reading and comprehension of the program.
And also: What is essential information should be clearly visible. Whitespace[^] was certainly created as a joke, but we may wonder if that was as a reply to languages that demark e.g. what is to be repeated, a loop body, by ... whitespace. OK, the number of (visible) tokens is reduced, but when the consiseness is based on invisible whitespace tokens that has essential semantic importance, then the language designers have gone too far in "consiseness"!
|
|
|
|
|
|
Kirk 10389821 wrote: If I gave you your "perfectly" concise language, without a bunch of caveats, like no libraries, no classes, no protocol support. Would you want to use it? If you had to implement AES, SMTP, HTTP, etc
i never said anything about eliminating libraries, classes, or protocol support.
|
|
|
|
|
johnywhy wrote: Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.
The boilerplate required in COBOL in order to encapsulate those three lines is going to be around another 300 lines of code, code which is not particularly human-readable 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I would say you rewrite fails the "Human understandable" test, as because my understanding of your code is quite different than what the original javascript does. I'd assume it was closer to:
var home =
{
get City ()
{
return "Boston"
}
};
Truth,
James
|
|
|
|
|
James Curran wrote: I would say you rewrite fails the "Human understandable" test, as because my understanding of your code is quite different than what the original javascript does.
You're interpreting "human readable" to mean "js-programmer readable". That's not what i mean. My rewrite throws out much js syntax, and can't be interpreted through a js lens. It's a different language.
|
|
|
|
|
|
File this one under Weird...or annoying.
Background
Created a little web app (including dotnet core Web Api) that allows me to read comics more easily. Because, I mean, why not.
I wanted to be able to save the date of the last comic I read to a remote location so I can then load it from any browser (any of my multiple devices) and keep reading the comics consecutively by date. I got it all working and it's a fun little hobby app.
The Problem
I pulled the app up on my TV via Amazon FireStick (runs Amazon Silk browser).
It all loaded up great. Then I attempted to press the button and nothing happened.
<button id="loadComicDatesButton" onclick="getComicDatesFromApi()" >Load Dates</button> onclick Not Supported On Mobile
This is considered a mobile browser and onclick is not supported. You need the touchstart event.
First Attempt to Fix
I looked it up and found documentation. I figured you could just add the ontouchstart="functionName()" to the button.
Nope!
You have to attach the event to the element using javascript.
document.querySelector("#loadComicDatesButton").addEventListener("touchstart",getComicDatesFromApi);I guess that is because the <button> element doesn't know about ontouchstart or something?? 
Other devs have probably figured this out and said this 1 million times before. But, it is still weird.
modified 11-May-20 15:30pm.
|
|
|
|
|
I thought browsers were supposed to fire the mouse events as well as the touch events for single-finger activation gestures?
Touch Events - Level 2[^]
Even Amazon's own documentation say they do:
Touch - Amazon Silk[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
