I've read that Java was designed to be usable by 'mediocre' programmers. I take it the idea was you could hire people who weren't master programmers and get something working that didn't have a lot of subtle bugs like memory leaks that were going to come back and haunt you later.
"Mediocre" is a matter of perspective. A Java programmer is more likely to be a generalist and do some degree of analysis work, such as gathering and clarifying requirements with customers.
C/C++ is used more often where hardware restraints/performance matter more and the programmers are either habitually or naturally more fastidious about the technical side and machine-level concerns. But they are also less likely to interact with or want to interact with end-users or non-technicians such as marketers.
I general I think there's a general trade-off between a mind that does well at technical issues versus people/business issues. Yes, there are exceptions, but I stand by the general rule. Paul Graham seems to agree as he mentioned that geeks in high school are often poor at social interaction because social interaction does not interest them any more than a football player is typically interested in gizmos or chess.
You should know saying "stuck with" will trigger a language flame-war. (Personally I believe such languages shine in different spots and it's almost comparing apples to oranges.)
Just spend the money on regular trains/trams. No ego contests comparable to having the tallest building. Overly fast trains are too easy to sabotage anyhow. Would you rather be in a train crashing at 600mph or 60mph?
I find the payphone dig unfair criticism. For one, it was hard to know then if airwaves could carry all the signals needed for consumer cell-phones. It took a while to perfect signal compression and other issues.
Second, it was hard to know if miniaturization of electronics (Moores' law) would continue. In fact, by many accounts it's stopping now. It's not really a law, just a recent pattern, with no guarantee of continuing.
You may then argue that if one assumes miniaturization slows, how come they have androids (strong AI) in the flick? But that assumes miniaturization is/was needed to get decent AI. There's no inherent law of the universe that says AI has to come from miniaturization. Perhaps a new algorithm or computing substance could be discovered to get AI without relying on shrinking parts. For example, if most the android's entire body is a "brain", then it's merely a big computer to get big computations. Or maybe an organic substance that's good for artificial brains but NOT for cell-phone miniaturization.
The accusers are biased by actual history where our AI advances HAPPENED TO come from mostly the same advances that our phones used. That wasn't an obvious or required assumption back then.
On a different aspect, the article made an interesting point in that the first electric motors didn't help factories much because the factories simply replaced the centralized steam systems with electric motors. It wasn't until factories decentralized power distribution that the real advantage of electricity played out. The environment around the gizmo has to change to fit the new technology before its benefits show.
Jet planes were similar: early attempts mostly just slapped a jet engine on a propeller-intended design, meaning performance often wasn't good enough to justify the extra cost and maintenance it required. It's only when planes were reworked around jet engines and the new speed that real results came. Most wind tunnels of the time didn't even have enough power to simulate jet speeds. They had to build new ones.
Either way, there should be a national vote on it before starting because of the potential bigly consequences. Otherwise, representatives with catch-phrases like "drill baby drill!" will make the decision for you.
"Contains" processes it case-neutral. Mass null-checks are only for stupid API's. Good ones rarely need them. Some fockers like to type and read bloat all day.
Can states override this for their own state to have state-wide NN? To hell with red states! Let them nuke their telecom competition to dust like the suckers they are and be forced to purchase Teletubbies in HD in order to see NASCAR in HD. The #@$%'s probably secretly like Teletubbies anyhow.
The "auto-composer" generates either MIDI or MIDI-like codes*, which I then feed into a MIDI player (synthesizer) of some kind. I also experimented with the "csound" library to actually generate sound (.WAV files), which gives one more control over the wave-forms, but I decided that's too much micromanagement needed by the bot, and went back to MIDI players. (Csound is fun to play with, though. It's better for "spacey" music than traditional.)
Keep in mind these are hobbyist and experimental gizmos. If I were a music pro (not) it would typically be converted into traditional "music sheet" staff notation and given to the band/orchestra to practice and play. Synthesizers are just a cheap shortcut, at least for a traditional sound.
* I like to generate an intermediate form that's a higher abstraction than MIDI (but later converted to MIDI), something like the following table (or CSV) structure:
- beat number, or maybe just a "new beat" marker - channel (instrument) - note number (note position on the keyboard or equiv.) - start tick (Example: 4th tick out of 8) - duration in ticks - velocity (intensity) - misc. special effects indicators, such as bend or slow ramp-up
Ticks are typically 8 per beat, but may be 16 for intricate music, or 6 per beat for 3/4 time (great for Renascence tunes). I'm not guaranteeing I'm using official vocab here.
Further, I recently devised a kind of musical ASCII short-hand that gives a current-chord perspective instead of an absolute "note" position perspective. It's real nutty, but I like it. It makes one think about melodies different than the usual approach. It's interesting how a different notation makes one think differently about song construction because it highlights patterns not readily visible in the typical approach. It's roughly comparable to the feeling of using polar coordinates instead of X/Y coordinates. Certain kinds of math transformations are just easier with polar coordinates when dealing with round stuff.
But do note (no pun intended) that my experiments were mostly focused on early classical music. "Bach era", if you will. (I even put one on SoundCloud, but don't feel like giving a link out just yet.)
George Washington failed almost all his battles, but took what he learned and pivoted into a sneak attack at Valley Forge.
It's more like he wore the British out, not outright failed. They were away from home in a strange land, and he just kept moving them around and around. US soldiers would rotate in and out, go back home to rest up and come back. He discovered attrition was our advantage. Most his battles were more or less break-evens, but the Brits didn't want to keep playing the break-even game.
DLL-Hell aside, VB classic was great for "git'er done" non-critical internal applications. It just was lousy at building API's meant to be used or shared in multiple applications.
Then maybe the Fox "War on Xmas" conspiracy is correct: liberals concoct global warming hoax to claim it's too hot to have Xmas. It's all falling into place now. (All while faking moon landings and covering up H's 38 murders. That's a lot of murders for somebody with {alleged} Parkinson's disease. Maybe she wiggles her victims to death.)
I have experimented with computer-composed music, and conclude it's fairly easy to make "pleasant" music: the rules for western ear expectations are fairly straight forward; stay within the rules and it'll sound "normal".
Markov-like chains of "hit tune" chord progressions can be mined, for example, to find decent chords. And there are fairly obvious rules for how the melody moves around a given chord and chord transitions, if you simply study diagrams/plots of several hits. The melody "likes" certain distances and relationships with regard to the active chord, sort of reminiscent of the probabilistic modelling of electron orbits (positions) relative to the center of the the atom. One can fine-tune the extraction of such patterns/formulas using statistics and AI (although I just eye-balled most of it myself and used some trial-and-error).
Now whether anyone finds music generated from such pattern mining highly entertaining and/or moving is another matter. For one, such is subjective: a pattern or technique that one person really likes, another may not. The hard part is not really generating ideas, but culling them. AI may indeed be able to cull based on patterns of existing hits to find a bigger audience, but after a while the easy-to-find patterns will get tired and stale to listeners. The low-hanging fruit will be all picked and people will want something different. It's why fads like disco, auto-tune, emo rock, and techno come and go.
Even if AI-using composers hone their techniques of generating candidate music, the hard part will still be culling against actual listeners: after all, AI does not buy music: only actual human "testers" will suffice. The cost of testing (getting listeners) will be about the same regardless of whether a tune is composed by a human or machine. Thus, you need to make sure the bot's quality is competitive with a human, or you are wasting money. On the web you still have to pay for attention (unless you get really lucky with cute hamsters or the like).
Another thing, my "music machines" tend to sound like my hand-composed music. It's modelling my own head more or less being I tune it based on my preference and by grabbing samples of stuff I like in order to extract patterns from. Thus, the artificial composer is sort of an extension of myself. It's just "implementing" my preferences.
Fastly? Since when is Trump writing summaries for Slashdot?
Trump sets trends for good or bad because he's in the news so often. When W was in office, people often copied his style also:
"The trumpificationism of linguistical discussionificationism has increasified."
Whether trump-speak lasts or not is another matter. Imagine the speech of their offspring if the 2 mated:
"I'm the bestified at speakificationism, believify me! The ratingnizing people givefy me biglified top resultifications. Huuugitized! I know more wordations than losercated English teachifiers! So sadditudes. #MAGAFICATE!"
OO models can be mapped 1:1 to relational ones. There are plenty of patterns to achieve that.
Of course they can. It's why I used the word "mostly". Whether it's practical/useful is another matter. OOP is generally based on inheritance and/or composition, which are hierarchical concepts. While OOP can "model" sets, it's not their forte. (AKA, Turing Tarpit.)
The problem comes if you already have an relational DB, which probably evolved and is no longer a pure design, and want to map that to oo.
After several years, usually no design is "pure". Changes often come that don't fit our original abstractions and we have to fudge the design with kludges. True, you can refactor databases and OOP, but most places don't fully bother for various reasons I won't delve into here. Another problem I see is forcing the relational model to look like object models (or OO-centric frameworks), such as using surrogate keys on many-to-many tables and doing joins on the client side to avoid creating another class/object.
100 lines C++ or Java implement 10 times more functionality [than assembler].
Not necessarily. The assembler coder can use clever tricks to save code and use extensive existing libraries to reduce reinvention of the wheel.
So do I with C++ and Java
Maybe you're a whiz at them; that's my point. One can say that if OTHERS are slow in your favorite tool/paradigm that they are just not yet skilled at it and/or dumb. Tools that are otherwise awkward or have huge learning curves to normal/average coders can be "justified" that way. One person is not a good test.
Our management tells us that "Agile Development" means that anyone can develop anything. Why would we need expensive chief architects anymore?
Technically that's true as it can be "hacked into shape" over time. But maintainability likely will be kicked in the nuts. PHB's don't think long term, or else they wouldn't be PHB's.
I was once tasked with maintaining a mostly-CRUD app written in Excel VBA by a non-programmer. Ugly-city. Maintainability matters. The PHB's are either clueless about the cost of maintenance, or hope to get promoted away before their Live-For-Today projects need real maintenance.
Slashdot Mirror
Che-matic
"Mediocre" is a matter of perspective. A Java programmer is more likely to be a generalist and do some degree of analysis work, such as gathering and clarifying requirements with customers.
C/C++ is used more often where hardware restraints/performance matter more and the programmers are either habitually or naturally more fastidious about the technical side and machine-level concerns. But they are also less likely to interact with or want to interact with end-users or non-technicians such as marketers.
I general I think there's a general trade-off between a mind that does well at technical issues versus people/business issues. Yes, there are exceptions, but I stand by the general rule. Paul Graham seems to agree as he mentioned that geeks in high school are often poor at social interaction because social interaction does not interest them any more than a football player is typically interested in gizmos or chess.
You should know saying "stuck with" will trigger a language flame-war. (Personally I believe such languages shine in different spots and it's almost comparing apples to oranges.)
Just spend the money on regular trains/trams. No ego contests comparable to having the tallest building. Overly fast trains are too easy to sabotage anyhow. Would you rather be in a train crashing at 600mph or 60mph?
I find the payphone dig unfair criticism. For one, it was hard to know then if airwaves could carry all the signals needed for consumer cell-phones. It took a while to perfect signal compression and other issues.
Second, it was hard to know if miniaturization of electronics (Moores' law) would continue. In fact, by many accounts it's stopping now. It's not really a law, just a recent pattern, with no guarantee of continuing.
You may then argue that if one assumes miniaturization slows, how come they have androids (strong AI) in the flick? But that assumes miniaturization is/was needed to get decent AI. There's no inherent law of the universe that says AI has to come from miniaturization. Perhaps a new algorithm or computing substance could be discovered to get AI without relying on shrinking parts. For example, if most the android's entire body is a "brain", then it's merely a big computer to get big computations. Or maybe an organic substance that's good for artificial brains but NOT for cell-phone miniaturization.
The accusers are biased by actual history where our AI advances HAPPENED TO come from mostly the same advances that our phones used. That wasn't an obvious or required assumption back then.
On a different aspect, the article made an interesting point in that the first electric motors didn't help factories much because the factories simply replaced the centralized steam systems with electric motors. It wasn't until factories decentralized power distribution that the real advantage of electricity played out. The environment around the gizmo has to change to fit the new technology before its benefits show.
Jet planes were similar: early attempts mostly just slapped a jet engine on a propeller-intended design, meaning performance often wasn't good enough to justify the extra cost and maintenance it required. It's only when planes were reworked around jet engines and the new speed that real results came. Most wind tunnels of the time didn't even have enough power to simulate jet speeds. They had to build new ones.
Seems the gov't doesn't block trolls.
In that case, we're turning you in.
Just outsource your browsing to Americans.
But, if it blows, nobody will live long nor prosper.
It would almost certainly have the phrase, "Probably just a routine tremor, no need to tell the boss about our little shortcut."
Either way, there should be a national vote on it before starting because of the potential bigly consequences. Otherwise, representatives with catch-phrases like "drill baby drill!" will make the decision for you.
"Contains" processes it case-neutral. Mass null-checks are only for stupid API's. Good ones rarely need them. Some fockers like to type and read bloat all day.
Can states override this for their own state to have state-wide NN? To hell with red states! Let them nuke their telecom competition to dust like the suckers they are and be forced to purchase Teletubbies in HD in order to see NASCAR in HD. The #@$%'s probably secretly like Teletubbies anyhow.
Take it away R2D2, ladies & gentlemen, he's the man!...
The "auto-composer" generates either MIDI or MIDI-like codes*, which I then feed into a MIDI player (synthesizer) of some kind. I also experimented with the "csound" library to actually generate sound (.WAV files), which gives one more control over the wave-forms, but I decided that's too much micromanagement needed by the bot, and went back to MIDI players. (Csound is fun to play with, though. It's better for "spacey" music than traditional.)
Keep in mind these are hobbyist and experimental gizmos. If I were a music pro (not) it would typically be converted into traditional "music sheet" staff notation and given to the band/orchestra to practice and play. Synthesizers are just a cheap shortcut, at least for a traditional sound.
* I like to generate an intermediate form that's a higher abstraction than MIDI (but later converted to MIDI), something like the following table (or CSV) structure:
- beat number, or maybe just a "new beat" marker
- channel (instrument)
- note number (note position on the keyboard or equiv.)
- start tick (Example: 4th tick out of 8)
- duration in ticks
- velocity (intensity)
- misc. special effects indicators, such as bend or slow ramp-up
Ticks are typically 8 per beat, but may be 16 for intricate music, or 6 per beat for 3/4 time (great for Renascence tunes). I'm not guaranteeing I'm using official vocab here.
Further, I recently devised a kind of musical ASCII short-hand that gives a current-chord perspective instead of an absolute "note" position perspective. It's real nutty, but I like it. It makes one think about melodies different than the usual approach. It's interesting how a different notation makes one think differently about song construction because it highlights patterns not readily visible in the typical approach. It's roughly comparable to the feeling of using polar coordinates instead of X/Y coordinates. Certain kinds of math transformations are just easier with polar coordinates when dealing with round stuff.
And closely related to the "4-chords":
https://www.youtube.com/watch?...
But do note (no pun intended) that my experiments were mostly focused on early classical music. "Bach era", if you will. (I even put one on SoundCloud, but don't feel like giving a link out just yet.)
It's more like he wore the British out, not outright failed. They were away from home in a strange land, and he just kept moving them around and around. US soldiers would rotate in and out, go back home to rest up and come back. He discovered attrition was our advantage. Most his battles were more or less break-evens, but the Brits didn't want to keep playing the break-even game.
DLL-Hell aside, VB classic was great for "git'er done" non-critical internal applications. It just was lousy at building API's meant to be used or shared in multiple applications.
Then maybe the Fox "War on Xmas" conspiracy is correct: liberals concoct global warming hoax to claim it's too hot to have Xmas. It's all falling into place now. (All while faking moon landings and covering up H's 38 murders. That's a lot of murders for somebody with {alleged} Parkinson's disease. Maybe she wiggles her victims to death.)
I have experimented with computer-composed music, and conclude it's fairly easy to make "pleasant" music: the rules for western ear expectations are fairly straight forward; stay within the rules and it'll sound "normal".
Markov-like chains of "hit tune" chord progressions can be mined, for example, to find decent chords. And there are fairly obvious rules for how the melody moves around a given chord and chord transitions, if you simply study diagrams/plots of several hits. The melody "likes" certain distances and relationships with regard to the active chord, sort of reminiscent of the probabilistic modelling of electron orbits (positions) relative to the center of the the atom. One can fine-tune the extraction of such patterns/formulas using statistics and AI (although I just eye-balled most of it myself and used some trial-and-error).
Now whether anyone finds music generated from such pattern mining highly entertaining and/or moving is another matter. For one, such is subjective: a pattern or technique that one person really likes, another may not. The hard part is not really generating ideas, but culling them. AI may indeed be able to cull based on patterns of existing hits to find a bigger audience, but after a while the easy-to-find patterns will get tired and stale to listeners. The low-hanging fruit will be all picked and people will want something different. It's why fads like disco, auto-tune, emo rock, and techno come and go.
Even if AI-using composers hone their techniques of generating candidate music, the hard part will still be culling against actual listeners: after all, AI does not buy music: only actual human "testers" will suffice. The cost of testing (getting listeners) will be about the same regardless of whether a tune is composed by a human or machine. Thus, you need to make sure the bot's quality is competitive with a human, or you are wasting money. On the web you still have to pay for attention (unless you get really lucky with cute hamsters or the like).
Another thing, my "music machines" tend to sound like my hand-composed music. It's modelling my own head more or less being I tune it based on my preference and by grabbing samples of stuff I like in order to extract patterns from. Thus, the artificial composer is sort of an extension of myself. It's just "implementing" my preferences.
It's gajillion degrees outside and you are talking about Xmas? Coal in your stocking.
Trump sets trends for good or bad because he's in the news so often. When W was in office, people often copied his style also:
"The trumpificationism of linguistical discussionificationism has increasified."
Whether trump-speak lasts or not is another matter. Imagine the speech of their offspring if the 2 mated:
"I'm the bestified at speakificationism, believify me! The ratingnizing people givefy me biglified top resultifications. Huuugitized! I know more wordations than losercated English teachifiers! So sadditudes. #MAGAFICATE!"
Of course they can. It's why I used the word "mostly". Whether it's practical/useful is another matter. OOP is generally based on inheritance and/or composition, which are hierarchical concepts. While OOP can "model" sets, it's not their forte. (AKA, Turing Tarpit.)
After several years, usually no design is "pure". Changes often come that don't fit our original abstractions and we have to fudge the design with kludges. True, you can refactor databases and OOP, but most places don't fully bother for various reasons I won't delve into here. Another problem I see is forcing the relational model to look like object models (or OO-centric frameworks), such as using surrogate keys on many-to-many tables and doing joins on the client side to avoid creating another class/object.
Not necessarily. The assembler coder can use clever tricks to save code and use extensive existing libraries to reduce reinvention of the wheel.
Maybe you're a whiz at them; that's my point. One can say that if OTHERS are slow in your favorite tool/paradigm that they are just not yet skilled at it and/or dumb. Tools that are otherwise awkward or have huge learning curves to normal/average coders can be "justified" that way. One person is not a good test.
Technically that's true as it can be "hacked into shape" over time. But maintainability likely will be kicked in the nuts. PHB's don't think long term, or else they wouldn't be PHB's.
I was once tasked with maintaining a mostly-CRUD app written in Excel VBA by a non-programmer. Ugly-city. Maintainability matters. The PHB's are either clueless about the cost of maintenance, or hope to get promoted away before their Live-For-Today projects need real maintenance.